وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

بعد از آپدیت اوبونتو آیا سرور به ریبوت نیاز دارد؟ راه تشخیص و برنامه‌ریزی

آموزش بررسی reboot-required، شناسایی سرویس‌های نیازمند restart و ریبوت کنترل‌شده سرور Ubuntu.

انتشار:
توسط تیم فنی نت‌آرام
۴ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله بعد از آپدیت اوبونتو آیا سرور به ریبوت نیاز دارد؟ راه تشخیص و برنامه‌ریزی در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
بعد از به‌روزرسانی Ubuntu، پیام System restart required می‌بینید. آیا باید همان لحظه سرور را خاموش و روشن کرد؟ پاسخ به بسته تغییرکرده، فوریت وصله و شرایط سرویس بستگی دارد. بعضی به‌روزرسانی‌ها با راه‌اندازی دوباره یک سرویس اثر می‌کنند و بعضی، مانند تغییر هسته در بسیاری از نصب‌ها، برای استفاده از نسخه جدید به بوت دوباره نیاز دارند.
در این راهنما نشانه‌های موجود را می‌خوانیم و سپس برای ریبوت احتمالی برنامه‌ریزی می‌کنیم. از بین بردن فایل هشدار به جای انجام اقدام لازم، خودِ به‌روزرسانی را فعال نمی‌کند.

۱. نشانه درخواست ریبوت را بخوانید

با SSH یا کنسول به سرور Ubuntu وارد شوید:
کد / دستورif [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required else echo 'No reboot-required marker found' fi
وجود این فایل نشان می‌دهد دست‌کم یک بسته در این سیستم درخواست ریبوت ثبت کرده است. نبود آن اثبات نمی‌کند همه سرویس‌ها از کتابخانه‌های تازه استفاده می‌کنند یا هیچ اقدام دیگری لازم نیست. در بسیاری از سیستم‌ها /var/run به /run متصل است.
اگر فایل فهرست بسته‌ها وجود دارد:
کد / دستورif [ -f /var/run/reboot-required.pkgs ]; then cat /var/run/reboot-required.pkgs fi
نام بسته‌ها می‌تواند برای یافتن دلیل کمک کند، اما زمان و فوریت اقدام را باید با نوع به‌روزرسانی و سیاست سرور تعیین کرد.

۲. هسته در حال اجرا و وضعیت سرویس‌ها را مقایسه کنید

کد / دستورuname -r uptime -s
فرمان اول نسخه هسته در حال اجرا و دومی زمان شروع سیستم را نشان می‌دهد. اگر بسته هسته تازه نصب شده، uname -r تا بوت در هسته جدید تغییر نمی‌کند. دیدن یک نسخه نصب‌شده در فهرست بسته‌ها تضمین نمی‌کند بوت بعدی حتماً همان نسخه را انتخاب می‌کند؛ تنظیم bootloader و پشتیبانی ارائه‌دهنده نیز مهم‌اند.
اگر needrestart روی سیستم نصب است، حالت فهرست می‌تواند سرویس‌هایی را که از کتابخانه قدیمی استفاده می‌کنند نشان دهد:
کد / دستورsudo needrestart -r l
گزینه l برای فهرست‌کردن است، نه راه‌اندازی خودکار سرویس‌ها. نسخه و تنظیم ابزار ممکن است متفاوت باشد. نتیجه را با کاربرد واقعی سرویس و دستورالعمل بسته تطبیق دهید. در هاست اشتراکی یا جایی که دسترسی مدیریتی ندارید، زمان به‌روزرسانی و هشدار را به مدیر سرویس اطلاع دهید.
اگر ابزار نصب نیست، از نبود خروجی نتیجه نگیرید که هیچ فرایندی نیاز به راه‌اندازی مجدد ندارد. می‌توانید راهنمای بسته به‌روزرسانی‌شده و سیاست تیم را بررسی کنید و در صورت نیاز از مدیر سیستم بخواهید ابزار سازگار توزیع را در زمان مناسب نصب کند. راه‌اندازی مجدد تک‌تک سرویس‌ها نیز می‌تواند نشست کاربران یا کارهای در حال اجرا را قطع کند؛ نام و وابستگی هر سرویس را پیش از اقدام بشناسید.

۳. پیش از ریبوت چه چیزهایی را آماده کنیم؟

از سلامت نسخه پشتیبان و امکان بازیابی مطمئن شوید. وضعیت سرویس‌های مهم، کارهای در حال اجرا، کاربران متصل و وابستگی‌ها را ببینید. برای پایگاه داده یا برنامه‌ای که کار طولانی انجام می‌دهد، روش توقف و شروع امن همان برنامه را رعایت کنید.
یک بازه کم‌ترافیک تعیین کنید و دسترسی جایگزین مانند کنسول پنل ماشین مجازی یا ارائه‌دهنده را پیش از قطع SSH امتحان کنید. اگر سرور از دیسک شبکه یا فایل‌سیستم راه دور استفاده می‌کند، امکان آماده‌شدن آن‌ها پس از بوت را بسنجید. در سامانه چندسروره، ترتیب خاموش و روشن‌شدن اجزا را از قبل مشخص کنید.

۴. ریبوت کنترل‌شده و بررسی پس از آن

اگر مدیر سیستم تصمیم به ریبوت گرفته و بازه مجاز آغاز شده است، فرمان زیر سرور را راه‌اندازی مجدد می‌کند و اتصال فعلی را قطع خواهد کرد:
کد / دستورsudo reboot
بعد از بالا آمدن، از طریق SSH یا کنسول مجدداً وارد شوید:
کد / دستورuptime -s uname -r systemctl --failed
زمان شروع باید با ریبوت تازه سازگار باشد. نسخه هسته را با نسخه مورد انتظار و سرویس‌های ناموفق را با وضعیت پیش از ریبوت مقایسه کنید. سپس وب‌سایت، ورود، پایگاه داده و کارهای مهم را با درخواست واقعی امتحان کنید؛ صرف پاسخ به ping یا وصل‌شدن SSH کافی نیست.

۵. اگر هشدار باقی ماند یا سرویس برنگشت

فهرست بسته‌های درخواست‌کننده ریبوت و گزارش بوت را ببینید:
کد / دستورjournalctl -b -p warning --no-pager
ممکن است به‌روزرسانی دیگری بعد از بوت انجام شده باشد یا هسته مورد انتظار بارگذاری نشده باشد. فایل نشانگر را برای پنهان‌کردن پیام دستی پاک نکنید. اگر سرویس بالا نمی‌آید، گزارش همان سرویس را بخوانید و از کنسول جایگزین و برنامه بازگشت استفاده کنید. برای کندی مرحله بوت، راهنمای systemd-analyze را ببینید.
برای رسیدگی تخصصی مدیریت سرور نت‌آرام و برای بررسی سرویس‌های نیازمند restart راهنمای needrestart اوبونتو در دسترس است.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام