چرا سرور لینوکسی ناگهان ریستارت شد؟ راهنمای پیدا کردن علت واقعی

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

در این راهنما ابتدا زمان راه‌اندازی را مشخص می‌کنیم، سپس گزارش قبل از آن را با رویدادهای زیرساخت کنار هم می‌گذاریم. هدف، پیدا کردن شواهد کافی برای اقدام مناسب است، نه نسبت دادن سریع مشکل به RAM، دیسک یا مرکز داده.

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

در SSH یا کنسول مجاز سرور، این دو دستور را اجرا کنید:

این دستورها زمان شروع کار سیستم فعلی را، در قالب‌های کمی متفاوت، نشان می‌دهند. زمان را با بازه قطعی سایت مقایسه کنید و منطقه زمانی سرور و ابزار پایش را نیز در نظر بگیرید. اگر زمان بوت خیلی قدیمی‌تر از زمان قطع سایت است، احتمالاً در آن رویداد فقط سرویس یا مسیر شبکه مختل شده؛ سراغ گزارش همان سرویس بروید.

در بعضی کانتینرها، محیط‌های محدود یا نسخه‌های متفاوت، معنی و دسترسی این خروجی‌ها فرق می‌کند. اگر دستور نتیجه نامعتبر داد، از مدیر مجازی‌ساز بخواهید وضعیت همان ماشین را با شناسه درست بررسی کند.

در سروری که systemd و journal در دسترس است، اجرا کنید:

هر ردیف یک شناسه بوت و بازه اولین و آخرین پیام ثبت‌شده برای آن را نشان می‌دهد. ردیف 0 معمولاً بوت فعلی و ردیف 1- بوت قبلی قابل مشاهده در گزارش است. این فهرست فقط بوت‌هایی را نشان می‌دهد که گزارششان هنوز در دسترس مانده؛ خالی بودن بوت قبلی به معنی اثبات نبودن ریستارت قبلی نیست.

برای دیدن انتهای گزارش بوت قبلی، اگر در فهرست وجود دارد:

این دستور آخرین ۱۵۰ پیام موجود در journal مربوط به بوت قبلی را می‌خواند. به زمان، نام سرویس و ترتیب رویدادها توجه کنید. ممکن است پیام خاموش شدن منظم، اجرای به‌روزرسانی، خطای جدی یا فقط قطع ناگهانی ثبت پیام‌ها را ببینید. قطع ناگهانی گزارش به‌تنهایی ثابت نمی‌کند برق رفته است؛ ممکن است پیام‌ها نوشته نشده یا در جایی دیگر نگهداری شده باشند.

برای دیدن پیام‌های کرنل در همان بوت قبلی:

به متن کامل خطا و زمان نگاه کنید. گزارش ممکن است نام کاربر، IP یا اطلاعات داخلی داشته باشد؛ قبل از ارسال آن برای دیگران، داده حساس را حذف کنید. مستندات journalctl معنی انتخاب بوت و فهرست آن را توضیح می‌دهد.

ممکن است journal فقط در حافظه موقت نگهداری شده، فایل‌ها به دلیل محدودیت نگهداری حذف شده یا دسترسی حساب شما کافی نباشد. در برخی سیستم‌ها گزارش‌ها در فایل‌های دیگری زیر /var/log یا سامانه جمع‌آوری لاگ مرکزی هستند. نبود گزارش دلیل قطعی نبودن رخداد نیست.

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

اگر سرویس برایتان مدیریت‌شده است، زمان تقریبی و شناسه ماشین را به ارائه‌دهنده بدهید تا رویدادهای مجازی‌ساز و زیرساخت همان بازه را بررسی کند. اطلاعات حساب یا رمز در گزارش لازم نیست.

| شواهد | نتیجه و اقدام مناسب | | --- | --- | | پیام واضح درخواست reboot یا خاموش شدن منظم در همان زمان | کاربر، سرویس یا کار زمان‌بندی‌شده ثبت‌شده را با گزارش‌های دیگر تطبیق دهید. نام یک فرایند به‌تنهایی همیشه هویت فرد دستوردهنده نیست. | | به‌روزرسانی در همان بازه ثبت شده | برنامه به‌روزرسانی و سیاست راه‌اندازی مجدد را بررسی کنید. هم‌زمانی به‌تنهایی اثبات نمی‌کند همان به‌روزرسانی فرمان ریستارت داده است. | | پیام Out of memory یا کشته شدن یک فرایند | این پیام می‌تواند علت توقف برنامه باشد؛ OOM معمولی الزاماً باعث ریستارت کل سرور نمی‌شود. زمان بوت و سیاست کرنل را جداگانه بررسی کنید. | | پیام kernel panic یا خطای سخت‌افزاری نزدیک پایان بوت | متن کامل، زمان و شناسه ماشین را نگه دارید و با مدیر سیستم و ارائه‌دهنده تطبیق دهید. یک خطا بدون زمینه برای نتیجه قطعی کافی نیست. | | گزارش ناگهان پایان یافته و رویداد دیگری ندارید | درباره علت قطعی نتیجه نگیرید؛ رویداد میزبان، کنترلر سخت‌افزار و مانیتورینگ را در همان بازه درخواست کنید. |

اگر سرور مجازی است، رویدادهای همان VM مانند خاموش شدن، ریست یا جابه‌جایی را در پنل مجازی‌ساز و با شناسه ماشین بررسی کنید. تغییر IP، نام مشابه یا تصویری از ماشین دیگر مدرک کافی برای نسبت دادن رویداد به سرور شما نیست. اگر سرور فیزیکی است، گزارش کنترلر سخت‌افزار و وضعیت برق و دما می‌تواند شواهد تکمیلی بدهد.

اگر کار زمان‌بندی‌شده مجاز در زمان نامناسب باعث راه‌اندازی مجدد شده است، تنظیم همان کار را با مالک آن به بازه نگهداری مناسب منتقل کنید و پس از تغییر، زمان‌بندی و هشدار را دوباره بررسی کنید. به‌روزرسانی‌های امنیتی را بدون برنامه جایگزین برای همیشه خاموش نکنید.

اگر یک سرویس به دلیل کمبود حافظه متوقف شده ولی سیستم بوت نشده، به جای ریست سرور، مصرف همان سرویس و علت رشد را با داده همان بازه دنبال کنید. اگر واقعاً kernel panic یا خطای ذخیره‌سازی ثبت شده، از تغییر تصادفی تنظیمات کرنل یا تعمیر آنلاین فایل‌سیستم خودداری کنید؛ پشتیبان و راه دسترسی مستقل را حفظ و بر اساس خطای واقعی برنامه بازیابی تهیه کنید.

اگر پنل مجازی‌ساز رویداد Reset یا Power action را نشان می‌دهد، زمان، شناسه VM و عامل ثبت‌شده را با گزارش سیستم تطبیق دهید. ممکن است لازم باشد سیاست خودکار، عملیات مدیر یا اختلال میزبان اصلاح شود؛ نتیجه باید از شواهد همان زیرساخت به دست آید.

حتی اگر سرور در دسترس است، برنامه‌ها ممکن است پس از بوت کامل بالا نیامده باشند. سرویس‌های مهم، اتصال پایگاه داده و خود سایت را از بیرون آزمایش کنید. برای هر سرویس شناخته‌شده می‌توانید وضعیت فعلی را ببینید؛ مثلاً اگر نام واقعی سرویس nginx است:

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

در پایان، زمان‌ها، خروجی پاک‌سازی‌شده، شناسه ماشین، اقدام و نتیجه آزمایش را ثبت کنید تا اگر مشکل تکرار شد مقایسه ممکن باشد. برای بررسی امکانات سرور، صفحه سرور مجازی ایران نت‌آرام در دسترس است.