محتوای آموزشی وبلاگ نت‌آرام
برنامه‌ای که از پوشه اشتراکی شبکه استفاده می‌کند ناگهان خطای
Stale file handle می‌دهد. گاهی فقط یک فایل باز نمی‌شود و گاهی کل پوشه NFS از دید کلاینت دچار مشکل است. این پیام معمولاً یعنی شناسه‌ای که کلاینت برای دسترسی به فایل یا پوشه نگه داشته، دیگر با شیء فعلی سمت سرور تطبیق ندارد؛ برای مثال ممکن است پوشه در سرور حذف و دوباره ساخته شده یا فایل‌سیستم پشت اشتراک تغییر کرده باشد.این خطا به‌خودی‌خود دستور حذف فایل یا ساخت دوباره داده نیست. در این راهنما ابتدا محدوده مشکل را مشخص می‌کنیم، بعد منبع اشتراک و برنامه‌های استفاده‌کننده را می‌شناسیم و در صورت نیاز فقط همان اتصال را دوباره برقرار می‌کنیم. مثال‌ها برای لینوکس در سرور مجازی ایران یا سرور اختصاصی ایران هستند. مسیر
/mnt/shared و سرور nfs.example.com نمونه‌اند. برای مسیر ریشه سیستم، ذخیره‌سازی پایگاه داده فعال یا سرویس‌های حساس بدون برنامه نگهداری اقدام به unmount نکنید.۱. مشکل فقط یک فایل است یا کل اشتراک؟
متن خطا، مسیر و زمان آن را از برنامه یا لاگ یادداشت کنید. اگر فقط یک فایل توسط یک برنامه باز مانده و بعد از جایگزینی آن در سرور خطا می‌دهد، ممکن است بستن و بازکردن دوباره فایل در همان برنامه کافی باشد. پیش از بستن، مطمئن شوید داده نوشته‌نشده‌ای از دست نمی‌رود. اگر چند برنامه و خود پوشه اشتراکی نیز خطا می‌دهند، به سراغ اتصال و منبع بروید.
گزارش هسته کلاینت را برای همان بازه ببینید:
کد / دستورsudo journalctl -k -b --no-pager | grep -i nfs
پیام
server not responding بیشتر به دسترسی شبکه یا پاسخ‌ندادن سرور اشاره دارد و با stale file handle یکی نیست؛ ممکن است هر دو هم‌زمان رخ دهند. خطا را با تغییرات اخیر سمت ذخیره‌سازی، زمان بازیابی بکاپ، جابه‌جایی مسیر یا ریبوت مقایسه کنید. اگر گزارش طولانی است، بازه زمانی مناسب را با گزینه‌های journalctl محدود کنید.۲. منبع و تنظیم اتصال فعلی را ثبت کنید
روی کلاینت، برای نقطه اتصال واقعی خود اجرا کنید:
کد / دستورfindmnt -M /mnt/shared -o TARGET,SOURCE,FSTYPE,OPTIONS
SOURCE سرور و مسیر صادرشده، FSTYPE نوع اتصال و OPTIONS تنظیمات آن را نشان می‌دهد. اگر خروجی خالی است، شاید /mnt/shared خودِ نقطه اتصال نباشد و فقط زیرپوشه یک mount دیگر باشد. در آن صورت مسیر پوشش‌دهنده را نیز ببینید:findmnt -T /mnt/shared -o TARGET,SOURCE,FSTYPE,OPTIONS
در مسیر شبکه خراب، بعضی دستورهایی که به خود فایل‌سیستم مراجعه می‌کنند ممکن است طولانی یا متوقف شوند. از یک نشست مدیریتی جدا استفاده کنید و اجرای پشت سر هم دستورهای بیشتر را متوقف کنید.
timeout هم همیشه نمی‌تواند پردازشی را که در انتظار غیرقابل‌قطع هسته است فوراً پایان دهد.اگر اتصال با fstab تنظیم شده، تعریف مربوط را ببینید:
کد / دستورgrep -n '/mnt/shared' /etc/fstab
آدرس سرور، مسیر اشتراک، نسخه و گزینه‌ها را با اطلاعات مورد انتظار مقایسه و قبل از تغییر ثبت کنید. خروجی تنظیمات ممکن است اطلاعات داخلی داشته باشد. برخی اتصال‌ها با systemd automount، autofs، کانتینر یا ابزار مدیریت دیگری ساخته می‌شوند و در fstab نیستند؛ در آن صورت روش همان ابزار را پیدا کنید. دستورهای یک روش را بدون شناخت روی روش دیگر اعمال نکنید.
۳. سمت سرور واقعاً همان داده در دسترس است؟
اگر دسترسی به سرور NFS دارید، از طریق کنسول یا SSH جداگانه وارد آن شوید. در مسیر سرور، که الزاماً با
کد / دستور/mnt/shared کلاینت یکی نیست، منبع فایل‌سیستم و export را ببینید. در مثال زیر مسیر صادرشده /srv/shared است:findmnt -T /srv/shared -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo exportfs -v
مقایسه کنید آیا فایل‌سیستم و export همان چیزی است که قبل از حادثه انتظار داشتید. اگر دیسک پشت
/srv/shared مانت نشده، ممکن است پوشه خالی روی فایل‌سیستم اصلی سرور دیده شود؛ آن را جای داده اصلی فرض نکنید. اگر پوشه از بکاپ بازسازی یا حذف و دوباره ساخته شده، نام یکسان الزاماً به معنی شناسه یکسان نیست. راهنمای Oracle نمونه جایگزینی یا حذف فایل سمت سرور را به‌عنوان علت این خطا توضیح می‌دهد.در صورت نبود داده یا منبع اشتباه، اول طبق روش ذخیره‌سازی خود دیسک و داده درست را بازیابی کنید.
exportfs -v تنظیمات مؤثر را نشان می‌دهد؛ اجرای بی‌هدف دستورهای حذف یا بازنویسی همه exportها ممکن است کلاینت‌های دیگر را مختل کند. تغییر تنظیم export فقط پس از شناخت اثر بر همه مصرف‌کنندگان انجام شود.۴. چه کسانی از اتصال استفاده می‌کنند؟
پیش از جداکردن mount، برنامه‌ها، کارهای بکاپ و کانتینرهای وابسته را شناسایی و یک زمان نگهداری انتخاب کنید. اگر ابزار
کد / دستورfuser نصب است، برای همان نقطه اتصال اجرا کنید:sudo fuser -vm /mnt/shared
گزارش ممکن است پردازش‌هایی را که به همان فایل‌سیستم دسترسی دارند نشان دهد و به‌تنهایی ثابت نمی‌کند بستن همه آن‌ها بی‌خطر است. نام هر سرویس و نقش آن را با تنظیمات خود تطبیق دهید. کار در حال نوشتن را با روش خود برنامه تمام یا متوقف کنید؛ از
fuser -k و کشتن گروهی پردازش‌ها استفاده نکنید. این بررسی نیز روی اتصال خراب ممکن است معطل شود.ترمینالی که داخل پوشه اشتراکی قرار دارد هم می‌تواند مانع جداشدن باشد. در هر نشست مدیریتی مربوط از آن خارج شوید:
کد / دستورcd /
اگر برنامه بکاپ در نبود mount به مسیر محلی زیر آن بنویسد، ممکن است دیسک اصلی پر شود یا داده در جای اشتباه قرار بگیرد. پیش از unmount اجرای چنین کارهایی را متوقف کنید. برای پیشگیری، راهنمای جلوگیری از نوشتن بکاپ روی دیسک اصلی روش بررسی mount و منبع را توضیح می‌دهد.
۵. اتصال مشخص را دوباره برقرار کنید
تنها وقتی منبع صحیح سمت سرور تأیید شده، عملیات وابسته متوقف شده و روش اتصال مجدد را می‌دانید، اتصال مورد نظر را جدا کنید:
کد / دستورsudo umount /mnt/shared
اگر پیام
target is busy دیدید، یک استفاده‌کننده هنوز اتصال را نگه داشته است. دوباره همان سرویس‌ها، نشست‌ها، bind mountها و کانتینرهای وابسته را بررسی کنید و بعد از بستن امن آن‌ها تلاش کنید. گزینه‌های lazy یا force ممکن است اتصال را از دید بخشی از سیستم پنهان کنند، در حالی که ارجاع‌ها یا عملیات معلق باقی‌اند؛ آن‌ها درمان عمومی نیستند و بدون برنامه بازیابی نباید استفاده شوند.اگر تعریف درست و تأییدشده آن نقطه در fstab وجود دارد، فقط همین مقصد را دوباره وصل کنید:
کد / دستورsudo mount /mnt/shared
این دستور همه فایل‌سیستم‌های fstab را مانت نمی‌کند. اگر fstab ورودی مربوط ندارد یا اتصال را autofs، systemd یا یک سامانه کانتینری مدیریت می‌کند، از روش همان سامانه و اطلاعات ثبت‌شده استفاده کنید. اگر mount شکست خورد، پیام را بخوانید و برنامه‌های وابسته را هنوز شروع نکنید؛ علت ممکن است مسیر export، مجوز کلاینت، DNS یا دسترسی شبکه باشد. از تغییر تمام مجوزها یا بازکردن فایروال برای همه استفاده نکنید.
۶. منبع درست و داده واقعی را تأیید کنید
پس از اتصال مجدد، دوباره فقط همان نقطه را ببینید:
کد / دستورfindmnt -M /mnt/shared -o TARGET,SOURCE,FSTYPE,OPTIONS
منبع و گزینه‌ها را با اطلاعات ثبت‌شده مقایسه کنید. سپس با کاربر واقعی برنامه، یک فایل شناخته‌شده را بخوانید یا در صورت مجازبودن، یک فایل آزمایشی کوچک در پوشه اختصاصی آزمون بسازید و همان را پاک کنید. در محیط چندکاربره از نام و پوشه‌ای استفاده کنید که متعلق به آزمون شماست و داده موجود را بازنویسی نکند. فقط پس از تأیید، سرویس‌های متوقف‌شده را با ترتیب مناسب بازگردانید و عملکرد واقعی برنامه را ببینید.
اگر دوباره خطا تکرار شد، به زمان جایگزینی پوشه، تغییر منبع، بازیابی snapshot و رخدادهای سرور NFS برگردید. برنامه‌ای که مرتب پوشه صادرشده را حذف و دوباره ایجاد می‌کند باید روش استقرار یا مسیر پایدار خود را اصلاح کند؛ remount مکرر به‌تنهایی جلوی تکرار را نمی‌گیرد. برای مشکل فقط یک فایل، بررسی کنید آیا برنامه هنوز handle قدیمی را باز نگه داشته است و همان فایل را با روش امن برنامه دوباره باز کنید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام