تابلوی آکادمی ویونیکس: انتخاب بوت، مقایسهٔ رویدادها و نگهداری شواهد

WIUNIX ACADEMY

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

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

متوسط15 دقیقه مطالعهبه‌روزرسانی
محیطت رو انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.

Rocky Linux 9بررسی‌شده با مستندات رسمی ·

از اینجا شروع کن

آخر این آموزش چی خواهیم داشت؟

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

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

Ubuntu، Debian، RHEL، Rocky Linux، AlmaLinux، Arch Linux و Manjaro رو می‌تونی در انتخاب‌گر پیدا کنی. مسیرها با مستندات بررسی شدن. این راهنما برای لینوکسیه که systemd داره. Windows، macOS و میزبان‌های بدون systemd این journal رو ندارن.

قبل از شروع

  • به ترمینال میزبان systemd و زمان حدودی قطعی نیاز داری. برای دیدن لاگ‌های کل سیستم، از حسابی که اجازهٔ خواندن journal داره یا از sudo مجاز استفاده کن.
  • اگه می‌خوای خروجی رو ذخیره کنی، اول یه پوشهٔ خصوصی آماده کن. ممکنه اسم حساب، آدرس شبکه یا حتی اطلاعات محرمانه‌ای که برنامه اشتباهی نوشته توی لاگ باشه.

از وقتی شروع کن که سرویس از دسترس خارج شد

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

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

01

قدم بعدی

مطمئن شو روی خود میزبان systemd هستی

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

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

bash

ترمینال مجاز روی میزبان درگیر

cat /etc/os-release
rpm -q systemd
ps -p 1 -o comm=
journalctl --version
از کجا بفهمم درست انجام شده؟

برای ادامهٔ مسیر میزبان، باید PID 1 برابر systemd باشه و journalctl نسخه‌ش رو نشون بده.

02

قدم بعدی

بوت درست رو از روی تاریخ پیدا کن

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

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

bash

ترمینال مجاز روی میزبان درگیر

journalctl --list-boots --utc --no-pager
از کجا بفهمم درست انجام شده؟

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

03

قدم بعدی

چند پیام آخر رو بخون و بازهٔ قطعی رو جدا کن

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

bash

ترمینال مجاز روی میزبان درگیر

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
از کجا بفهمم درست انجام شده؟

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

04

قدم بعدی

شروع بوت فعلی رو هم ببین

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

bash

ترمینال مجاز روی میزبان درگیر

journalctl -b 0 --utc --no-pager -o short-iso-precise | head -n 35
از کجا بفهمم درست انجام شده؟

پیام‌های اولی که از این بوت باقی مونده کمک می‌کنن زمان قطعی رو دقیق‌تر پیدا کنی. ممکنه اتفاق‌هایی قبل از شروع ثبت لاگ افتاده باشه.

05

قدم بعدی

پیام‌های سرویس و کرنل رو کنار هم بذار

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

bash

ترمینال مجاز روی میزبان درگیر

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
از کجا بفهمم درست انجام شده؟

هر دو خروجی برای همون بوت و همون بازه‌ان، پس می‌تونی ترتیب اتفاق‌های سرویس و کرنل رو مقایسه کنی.

همهٔ آموزش‌های آکادمی ↗