چگونه دلیل ریستارت شدن سرور لینوکس را پیدا کنیم؟ (راهنمای جامع عیب‌یابی)

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

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

قدم اول: بررسی تاریخچه بوت و ورود کاربران

قبل از هر چیز، باید بفهمیم سرور دقیقا چه زمانی ریبوت شده است.

۱. مشاهده زمان آخرین بوت با `who`

این ساده‌ترین دستور برای دیدن زمان دقیق آخرین باری است که سیستم‌عامل راه‌اندازی شده است.

who -b

خروجی چیزی شبیه به این خواهد بود: system boot 2024-08-15 10:30

۲. بررسی تاریخچه کامل ریبوت‌ها با `last`

دستور `last reboot` تمام ریبوت‌های ثبت شده در سیستم را به همراه زمان دقیق آن‌ها به شما نشان می‌دهد. این دستور به شما کمک می‌کند تا الگوهای زمانی (مثلا آیا سرور هر شب در یک ساعت خاص ریبوت می‌شود؟) را پیدا کنید.

last reboot

دستور `last` به تنهایی نیز تاریخچه ورود و خروج تمام کاربران را نمایش می‌دهد. با بررسی آن می‌توانید ببینید آیا قبل از زمان ریبوت، کاربری به سرور متصل بوده است یا خیر.

قدم دوم: تحلیل لاگ‌های سیستمی با `journalctl` (روش مدرن)

در تمام توزیع‌های مدرن لینوکس (اوبونتو، دبیان، AlmaLinux و…)، `journald` سرویس اصلی مدیریت لاگ‌ها است و `journalctl` ابزار ما برای خواندن این لاگ‌هاست. این قدرتمندترین ابزار برای پیدا کردن علت ریبوت است.

۱. لیست کردن تمام بوت‌های ثبت شده

این دستور به شما یک لیست از تمام دفعاتی که سیستم بوت شده را به همراه یک شناسه (ID) برای هر کدام نمایش می‌دهد.

journalctl --list-boots

خروجی به شما چیزی شبیه به این را نشان می‌دهد:

-2 a23c7080... Sat 2024-08-13 20:09:30 — Sat 2024-08-13 20:10:44
-1 94b604a6... Sat 2024-08-13 20:10:59 — Sat 2024-08-13 20:23:18
 0 3ff7e29f... Sat 2024-08-13 20:24:57 — Sat 2024-08-13 21:13:15

۲. بررسی لاگ‌های بوت قبلی

حالا می‌توانید لاگ‌های مربوط به بوت قبلی (که در آن ریبوت ناگهانی رخ داده) را بررسی کنید. برای این کار از شناسه -1 (آخرین بوت قبل از بوت فعلی) استفاده می‌کنیم:

journalctl -b -1 -p err

توضیح دستور:

• -b -1: به `journalctl` می‌گوید که لاگ‌های مربوط به بوت “منفی یک” (آخرین بوت قبلی) را نمایش بده.
• -p err: فقط پیام‌هایی با اولویت “error” یا بالاتر را فیلتر می‌کند تا خروجی خلوت‌تر شود.

با دقت آخرین خطوط این لاگ را بررسی کنید. معمولا پیام‌هایی مربوط به “Shutting down” (در صورت ریبوت دستی) یا خطاهای کرنل (Kernel Panic) در این بخش قابل مشاهده هستند.

قدم سوم: بررسی دلایل احتمالی دیگر

۱. خطاهای سخت‌افزاری (Hardware Issues)

گاهی اوقات مشکلات سخت‌افزاری مانند نقص در حافظه RAM یا داغ شدن بیش از حد CPU می‌تواند باعث ریبوت ناگهانی شود. دستور `dmesg` لاگ‌های کرنل را نمایش می‌دهد که می‌تواند شامل پیام‌هایی در مورد خطاهای سخت‌افزاری باشد.

sudo dmesg | grep -i "error\|fail\|warn"

۲. کمبود حافظه (Out of Memory)

اگر یک فرآیند تمام حافظه RAM سرور را مصرف کند، “OOM Killer” (قاتل کمبود حافظه) در کرنل لینوکس فعال شده و آن فرآیند را برای نجات سیستم از کار می‌اندازد. در موارد شدید، این اتفاق می‌تواند منجر به ناپایداری و ریبوت شود. برای جلوگیری از فعال شدن OOM Killer و ناپایداری، اطمینان از اینکه سرور شما دارای منابع کافی است بسیار مهم است. اینجاست که اهمیت انتخاب VPS با RAM مناسب مشخص می‌شود.

با دستور زیر می‌توانید در لاگ‌های کرنل به دنبال پیام‌های مربوط به OOM Killer بگردید:

sudo journalctl -k | grep -i "out of memory"

۳. کرنل پنیک (Kernel Panic)

این یک خطای بسیار جدی در سطح کرنل سیستم‌عامل است که سیستم را در یک وضعیت غیرقابل بازیابی قرار می‌دهد و معمولا منجر به ریبوت خودکار می‌شود. لاگ‌های مربوط به Kernel Panic معمولا در `journalctl` یا `/var/log/syslog` ثبت می‌شوند.

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