بعد از ری‌استارت، لاگ بوت قبلی لینوکس رو پیدا کن

اگه با ترمینال کانتینر یا محیط نجات اومدی، ممکنه PID 1 و لاگ‌هایی که می‌بینی مال همون محیط باشن. اول توزیع، PID 1 و نسخهٔ journalctl رو ببین تا گزارش اشتباهی رو به سرور اصلی نسبت ندی.

journalctl همراه بستهٔ systemd میاد؛ برای خوندن لاگ نیازی به نصب دوبارهٔ systemd یا عوض‌کردن init نداری.

cat /etc/os-release
pacman -Q systemd
ps -p 1 -o comm=
journalctl --version

فهرست بوت‌هایی رو می‌گیریم که journal هنوز می‌تونه بخونه. معمولاً 0 بوت فعلیه و ‎-1 ردیف قبلی؛ این شماره‌ها تضمین نمی‌کنن که لاگ همهٔ ری‌استارت‌ها باقی مونده. تاریخ‌ها رو با زمان قطعی مقایسه کن و شناسهٔ کامل بوت رو بردار تا اگه سرور دوباره ری‌استارت شد، هنوز همون بوت رو بررسی کنی.

اگه هشدار دسترسی گرفتی یا فهرست کوتاه‌تر از چیزیه که انتظار داشتی، قبل از نتیجه‌گیری همین فهرست رو با sudo مجاز ببین.

journalctl --list-boots --utc --no-pager

توی همین ترمینال، شناسهٔ بوت خودت رو جای مقدار نمونه بذار و زمان شروع و پایان رو به UTC، اطراف همون هشدار تنظیم کن. اول ۴۰ پیام آخر رو می‌خونیم تا ببینیم بوت چطور تموم شده، بعد بازهٔ قطعی رو جدا می‌کنیم. فعلاً فقط پیام‌های خطا رو نگیر؛ پیام‌های عادی خاموش‌شدن هم می‌تونن کمک کنن. اگه فهرست بوت رو با sudo خوندی، برای خواندن‌های بعدی journalctl هم از همون دسترسی مجاز استفاده کن. فایل خروجی رو با حساب خودت بساز. برای دیدن شروع بوت فعلی، پنل جداگانهٔ پایین رو اجرا کن.

boot_id=PASTE_FULL_BOOT_ID
start='2026-11-15 08:10:00 UTC'
end='2026-11-15 08:20:00 UTC'
journalctl -b "$boot_id" -n 40 --utc --no-pager -o short-iso-precise
journalctl -b "$boot_id" --since "$start" --until "$end" --utc --no-pager -o short-iso-precise

۳۵ خط اول خروجی این بوت رو ببین؛ ممکنه خط اول فقط عنوان خروجی journal باشه. اگه بعد از قطعی چند بار دیگه ری‌استارت شده، به‌جای 0 شناسهٔ بوتی رو بذار که درست بعد از قطعی شروع شده.

journalctl -b 0 --utc --no-pager -o short-iso-precise | head -n 35

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

unit=example.service
journalctl -b "$boot_id" -u "$unit" --since "$start" --until "$end" --utc --no-pager
journalctl -b "$boot_id" -k --since "$start" --until "$end" --utc --no-pager