journalctl -b؛ بررسی خطاهای Boot در لینوکس

اگر یک سرور لینوکسی بعد از Reboot به‌درستی بالا نمی‌آید، یک Service اجرا نمی‌شود، Mount انجام نمی‌شود یا Network بعد از Boot در دسترس نیست، یکی از مهم‌ترین منابع برای پیدا کردن علت خطا System Journal است.

در سیستم‌های مبتنی بر systemd می‌توان با دستور:

Bash

journalctl -b

Copy

journalctl -b

Bash

فقط Logهای مربوط به Boot فعلی را مشاهده کرد.

این ویژگی باعث می‌شود به‌جای جستجو بین Logهای چند روز یا چند هفته، فقط اتفاقاتی را بررسی کنیم که از زمان روشن شدن سیستم تا لحظه فعلی رخ داده‌اند. مستندات رسمی systemd گزینه -b یا --boot را برای محدود کردن Journal به یک Boot مشخص تعریف می‌کنند.

در این مقاله روش بررسی خطاهای بوت، Serviceهای ناموفق، خطاهای Kernel، Mount و Network با journalctl را بررسی می‌کنیم.

دستور `journalctl -b` چه کاری انجام می‌دهد؟

دستور:

Bash

journalctl -b

Copy

journalctl -b

Bash

Logهای مربوط به Boot فعلی را نمایش می‌دهد.

برای مثال ممکن است خروجی از لحظه شروع Kernel آغاز شود:

journalctl -b؛ بررسی خطاهای Boot در لینوکس

این خروجی می‌تواند شامل پیام‌های مربوط به:

Kernel

systemd
Storage
Network
Filesystem
Serviceها
Hardware
Authentication

باشد.

چرا `journalctl -b` بهتر از `journalctl` ساده است؟

اگر فقط اجرا کنیم:

Bash

journalctl

Copy

journalctl

Bash

ممکن است Logهای مربوط به چند Boot مختلف نمایش داده شوند.

اما:

Bash

journalctl -b

Copy

journalctl -b

Bash

فقط Boot فعلی را نشان می‌دهد.

در نتیجه برای ایرادی که بعد از آخرین Reboot ایجاد شده است، خروجی بسیار مرتبط‌تری خواهیم داشت.

اجرای journalctl با sudo

بعضی Logهای System Journal ممکن است برای User معمولی قابل مشاهده نباشند.

بنابراین برای بررسی کامل‌تر بهتر است از:

Bash

sudo journalctl -b

Copy

sudo journalctl -b

Bash

استفاده شود.

اعضای بعضی Groupها مانند systemd-journal، adm یا wheel نیز بسته به Distribution ممکن است دسترسی بیشتری به Journal داشته باشند.

خروج از journalctl

خروجی journalctl معمولاً داخل Pager مانند:

less

نمایش داده می‌شود.

برای خروج:

را فشار دهید.

برای حرکت بین خطوط نیز می‌توانید از Arrow Keyها، Page Up و Page Down استفاده کنید. اگر با سیستم vim آشنایی دارید امکان حرکت با کلیدهای hjkl و جستجو در فایل با / نیز وجود دارد.

نمایش Log بدون Pager

اگر می‌خواهید خروجی مستقیماً در Terminal چاپ شود:

Bash

sudo journalctl -b --no-pager

Copy

sudo journalctl -b --no-pager

Bash

این گزینه برای Pipe کردن خروجی یا Copy کردن Log نیز مفید است.

مشاهده Bootهای ثبت‌شده

برای دیدن Bootهایی که Journal از آن‌ها Log نگهداری کرده است:

Bash

journalctl --list-boots

Copy

journalctl --list-boots

Bash

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

عدد 0مربوط به Boot فعلی است. عدد 1 مربوط به ۱ boot قبل‌تر و 2 دو boot قبل را نمایش ‌می‌دهد.

systemd اجازه انتخاب Boot بر اساس Offset یا Boot ID را می‌دهد.

بررسی Boot قبلی

گاهی سیستم در Boot قبلی مشکل داشته و Administrator مجبور شده Server را Reboot کند.

در این حالت Boot فعلی ممکن است کاملاً سالم باشد.

برای بررسی Boot قبلی:

Bash

sudo journalctl -b -1

Copy

sudo journalctl -b -1

Bash

برای دو Boot قبل:

Bash

sudo journalctl -b -2

Copy

sudo journalctl -b -2

Bash

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

Server crash
Unexpected reboot
Failed service
Filesystem problem
Kernel error
Network failure

بسیار کاربردی است.

چرا `journalctl -b -1` گاهی چیزی نمایش نمی‌دهد؟

این مورد بسیار مهم است.

اگر Journal به‌صورت volatile ذخیره شده باشد، Logها ممکن است فقط در:

/run/log/journal/

قرار داشته باشند.

محتوای /run بعد از Reboot باقی نمی‌ماند.

در مقابل، Persistent Journal معمولاً در:

/var/log/journal/

ذخیره می‌شود. تنظیم Storage= در journald.conf مشخص می‌کند Journal به‌صورت persistent، volatile یا حالت‌های دیگر ذخیره شود.

بنابراین اگر:

Bash

journalctl --list-boots

Copy

journalctl --list-boots

Bash

فقط Boot فعلی را نشان می‌دهد، ممکن است Log Boot قبلی اصلاً نگهداری نشده باشد.

بررسی Persistent Journal

ابتدا بررسی کنید:

Bash

ls -ld /var/log/journal

Copy

ls -ld /var/log/journal

Bash

اگر Directory وجود داشته باشد، معمولاً Persistent Journal فعال است.

همچنین می‌توانید Configuration را بررسی کنید:

Bash

grep -E 'Storage=' /etc/systemd/journald.conf

Copy

grep -E 'Storage=' /etc/systemd/journald.conf

Bash

مقادیر احتمالی شامل:

auto
persistent
volatile
none

هستند.

برای جزئیات دقیق Storage، مستندات رسمی journald.conf را بررسی کنید.

نمایش فقط Errorهای Boot

مشاهده تمام Logهای Boot ممکن است خروجی بسیار زیادی ایجاد کند.

برای نمایش پیام‌های سطح Error و مهم‌تر:

Bash

sudo journalctl -b -p err

Copy

sudo journalctl -b -p err

Bash

Priorityهای Journal از مهم‌ترین به کم‌اهمیت‌ترین به شکل زیر هستند:

emerg
alert
crit
err
warning
notice
info
debug

اگر:

-p err

استفاده شود، پیام‌های err و سطح‌های مهم‌تر مانند crit، alert و emerg نمایش داده می‌شوند.

بررسی Error و Warning

برای بررسی گسترده‌تر می‌توان Warningها را نیز نمایش داد:

Bash

sudo journalctl -b -p warning

Copy

sudo journalctl -b -p warning

Bash

این دستور:

warning
err
crit
alert
emerg

را نمایش می‌دهد.

برای Troubleshooting اولیه، این دستور معمولاً بسیار کاربردی است:

Bash

sudo journalctl -b -p warning --no-pager

Copy

sudo journalctl -b -p warning --no-pager

Bash

آیا هر Warning به معنی مشکل واقعی است؟

خیر.

وجود warning یا حتی error در Journal الزاماً به معنی وجود یک ایراد جدی در Server نیست.

ممکن است یک Driver اختیاری، Device غیرفعال یا Service بلااستفاده Error ثبت کرده باشد.

بنابراین هر پیام باید در Context وضعیت واقعی Server بررسی شود.

پیدا کردن Serviceهای Failed

یکی از اولین دستورات بعد از Boot مشکل‌دار:

Bash

systemctl --failed

Copy

systemctl --failed

Bash

است.

خروجی ممکن است شبیه زیر باشد:

اگر Service ناموفق پیدا شد، ابتدا:

Bash

systemctl status example.service

Copy

systemctl status example.service

Bash

و سپس:

Bash

journalctl -b -u example.service

Copy

journalctl -b -u example.service

Bash

را بررسی کنید.

برای آموزش کامل مدیریت Serviceها:

آموزش کامل systemctl

بررسی Errorهای یک Service

می‌توان Unit و Priority را با هم ترکیب کرد:

Bash

sudo journalctl -b -u nginx.service -p err

Copy

sudo journalctl -b -u nginx.service -p err

Bash

یا:

Bash

sudo journalctl -b -u mariadb.service -p warning

Copy

sudo journalctl -b -u mariadb.service -p warning

Bash

در نتیجه فقط Logهای مرتبط با همان Service نمایش داده می‌شوند.

مثال: Nginx بعد از Boot بالا نمی‌آید

ابتدا:

Bash

systemctl status nginx

Copy

systemctl status nginx

Bash

فرض کنیم خروجی:

Bash

Active: failed

Copy

Active: failed

Bash

باشد.

سپس:

Bash

sudo journalctl -b -u nginx

Copy

sudo journalctl -b -u nginx

Bash

ممکن است ببینید:

nginx[842]: nginx: [emerg] bind() to 0.0.0.0:80 failed
nginx[842]: nginx: [emerg] still could not bind()
systemd[1]: nginx.service: Main process exited
systemd[1]: Failed to start nginx.service

در این مثال مشکل Boot نیست؛ Service هنگام Boot اجرا شده اما نتوانسته Port 80 را Bind کند.

در مرحله بعد باید بررسی کرد چه Process دیگری Port را اشغال کرده است.

بررسی Kernel Logهای Boot

برای نمایش فقط Kernel Messageهای Boot فعلی:

Bash

sudo journalctl -k -b

Copy

sudo journalctl -k -b

Bash

گزینه -k خروجی را به Kernel Messageها محدود می‌کند.

این دستور برای بررسی مواردی مانند:

Disk Error
Driver Problem
Network Interface
Filesystem
OOM
Hardware
Kernel Warning

مفید است.

بررسی Kernel Errorها

برای نمایش Kernel Errorهای Boot:

Bash

sudo journalctl -k -b -p err

Copy

sudo journalctl -k -b -p err

Bash

برای Warning و بالاتر:

Bash

sudo journalctl -k -b -p warning

Copy

sudo journalctl -k -b -p warning

Bash

این دستور می‌تواند هنگام بررسی Serverی که بعد از Boot Device یا Storage خاصی را نمی‌شناسد بسیار مفید باشد.

مثال: Disk یا Filesystem مشکل دارد

می‌توان ابتدا Kernel Journal را بررسی کرد:

Bash

sudo journalctl -k -b

Copy

sudo journalctl -k -b

Bash

و سپس به دنبال عباراتی مانند:

I/O error
filesystem error
EXT4-fs
XFS
device timeout
Buffer I/O error

گشت.

با توجه به مقاله قبلی می‌توان از grep نیز کمک گرفت:

Bash

sudo journalctl -k -b | grep -Ei "error|I/O|filesystem|ext4|xfs"

Copy

sudo journalctl -k -b | grep -Ei "error|I/O|filesystem|ext4|xfs"

Bash

برای آموزش کامل‌تر جستجو:

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

بررسی Mountهای ناموفق

یکی از مشکلات رایج بعد از Boot این است که یک Disk یا Network Mount به‌درستی Mount نمی‌شود.

ابتدا:

Bash

systemctl --failed

Copy

systemctl --failed

Bash

را بررسی کنید.

ممکن است Unitی مانند:

mnt-backup.mount

در حالت Failed باشد.

سپس:

Bash

sudo journalctl -b -u mnt-backup.mount

Copy

sudo journalctl -b -u mnt-backup.mount

Bash

را اجرا کنید.

برای جستجوی کلی Mount Errorها:

Bash

sudo journalctl -b | grep -Ei "mount|failed to mount|dependency failed"

Copy

sudo journalctl -b | grep -Ei "mount|failed to mount|dependency failed"

Bash

بررسی `/etc/fstab`

اگر Boot به دلیل Mount مشکل دارد، فایل:

/etc/fstab

یکی از مهم‌ترین موارد برای بررسی است.

مشکلات رایج:

Wrong UUID
Missing disk
Wrong filesystem
Incorrect mount option
Unavailable network storage

برای نمایش UUIDها:

Bash

lsblk -f

Copy

lsblk -f

Bash

یا:

Bash

blkid

Copy

blkid

Bash

سپس اطلاعات را با /etc/fstab مقایسه کنید.

برای آموزش lsblk:

آموزش کامل دستور lsblk در لینوکس

بررسی Network بعد از Boot

اگر Server بالا آمده ولی Network فعال نشده است، ابتدا Interfaceها را بررسی کنید:

Bash

ip addr

Copy

ip addr

Bash

سپس:

Bash

ip route

Copy

ip route

Bash

اگر سیستم از NetworkManager استفاده می‌کند:

Bash

systemctl status NetworkManager

Copy

systemctl status NetworkManager

Bash

و:

Bash

sudo journalctl -b -u NetworkManager

Copy

sudo journalctl -b -u NetworkManager

Bash

را بررسی کنید.

برای systemd-networkd:

Bash

systemctl status systemd-networkd

Copy

systemctl status systemd-networkd

Bash

و:

Bash

sudo journalctl -b -u systemd-networkd

Copy

sudo journalctl -b -u systemd-networkd

Bash

پیدا کردن خطای DHCP

برای NetworkManager می‌توان:

Bash

sudo journalctl -b -u NetworkManager | grep -Ei "dhcp|failed|timeout|error"

Copy

sudo journalctl -b -u NetworkManager | grep -Ei "dhcp|failed|timeout|error"

Bash

را بررسی کرد.

ممکن است پیام‌هایی درباره:

DHCP timeout
No carrier
Link down
Gateway unavailable

مشاهده شود.

بررسی Boot قبلی بعد از Crash

فرض کنید Server Crash کرده و مجبور شده‌اید Reboot کنید.

بعد از بالا آمدن Server، مهم‌ترین Log ممکن است Boot فعلی نباشد.

ابتدا:

Bash

journalctl --list-boots

Copy

journalctl --list-boots

Bash

و سپس:

Bash

sudo journalctl -b -1

Copy

sudo journalctl -b -1

Bash

را اجرا کنید.

برای Errorهای Boot قبلی:

Bash

sudo journalctl -b -1 -p err

Copy

sudo journalctl -b -1 -p err

Bash

و برای Kernel:

Bash

sudo journalctl -k -b -1

Copy

sudo journalctl -k -b -1

Bash

این روش می‌تواند آخرین پیام‌های ثبت‌شده قبل از Crash یا Reboot را نشان دهد.

مشاهده آخرین پیام‌های Boot قبلی

اگر به دنبال Eventهای آخر قبل از Crash هستید:

Bash

sudo journalctl -b -1 -e

Copy

sudo journalctl -b -1 -e

Bash

گزینه -e خروجی را به انتهای Journal منتقل می‌کند.

برای مثال ممکن است آخرین پیام‌ها شامل:

Out of memory
I/O error
kernel panic
watchdog
service crash

باشند.

بررسی Out of Memory

اگر Server ناگهان Serviceها را Kill کرده یا Reboot شده است، OOM را بررسی کنید:

Bash

sudo journalctl -k -b | grep -Ei "oom|out of memory|killed process"

Copy

sudo journalctl -k -b | grep -Ei "oom|out of memory|killed process"

Bash

برای Boot قبلی:

Bash

sudo journalctl -k -b -1 | grep -Ei "oom|out of memory|killed process"

Copy

sudo journalctl -k -b -1 | grep -Ei "oom|out of memory|killed process"

Bash

ممکن است خروجی شبیه:

Out of memory: Killed process 1842 (php-fpm)

باشد.

در این حالت مشکل به کمبود RAM یا مصرف بیش از حد Processها مرتبط است.

مقاله مرتبط:

اگر منابع سرور لینوکسی کامل درگیر شد چکار کنیم؟

محدود کردن Log به یک بازه زمانی

اگر زمان بروز ایراد مشخص است، لازم نیست تمام Boot را بررسی کنیم.

برای مثال:

Bash

sudo journalctl -b --since "09:10"

Copy

sudo journalctl -b --since "09:10"

Bash

یا:

Bash

sudo journalctl -b \
  --since "2026-09-07 09:10:00" \
  --until "2026-09-07 09:20:00"

Copy

sudo journalctl -b \
  --since "2026-09-07 09:10:00" \
  --until "2026-09-07 09:20:00"

Bash

journalctl از --since و --until برای محدود کردن خروجی بر اساس زمان پشتیبانی می‌کند.

این روش در سرورهایی با حجم Log زیاد بسیار مفید است.

مشاهده Log از چند دقیقه اخیر

می‌توان از زمان نسبی نیز استفاده کرد:

Bash

sudo journalctl -b --since "-10 min"

Copy

sudo journalctl -b --since "-10 min"

Bash

یا:

Bash

sudo journalctl -b --since "-1 hour"

Copy

sudo journalctl -b --since "-1 hour"

Bash

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

بررسی Boot با grep

اگر به دنبال عبارت خاصی هستید:

Bash

sudo journalctl -b | grep -i "failed"

Copy

sudo journalctl -b | grep -i "failed"

Bash

یا:

Bash

sudo journalctl -b \
  | grep -Ei "error|failed|critical|timeout"

Copy

sudo journalctl -b \
  | grep -Ei "error|failed|critical|timeout"

Bash

این روش برای جستجوی سریع مناسب است، اما journalctl خودش قابلیت Filter بر اساس Priority، Unit و Time دارد و در بسیاری از موارد بهتر است ابتدا از همان Filterهای داخلی استفاده شود.

بررسی یک Device مشخص

Journal می‌تواند Log مرتبط با بعضی Deviceها یا مسیرهای Device را نیز نمایش دهد.

برای مثال:

Bash

sudo journalctl /dev/sda

Copy

sudo journalctl /dev/sda

Bash

در سرورهایی که Disk خاصی مشکل دارد، این روش می‌تواند در کنار Kernel Journal مفید باشد.

بررسی Dependency Failed

گاهی Service اصلی ایرادی ندارد، اما یکی از Dependencyهای آن Failed شده است.

مثلاً:

Dependency failed for Example Application.

ابتدا:

Bash

systemctl --failed

Copy

systemctl --failed

Bash

سپس:

Bash

sudo journalctl -b | grep -i "dependency failed"

Copy

sudo journalctl -b | grep -i "dependency failed"

Bash

را اجرا کنید.

بعد Unit مربوط به Dependency را پیدا کرده و Log همان Unit را جداگانه بررسی کنید.

بررسی Boot Time

اگر Server بدون Error بالا می‌آید اما Boot بسیار کند شده است، ابزارهای systemd می‌توانند علت تأخیر را مشخص کنند.

برای مشاهده زمان کلی Boot:

Bash

systemd-analyze

Copy

systemd-analyze

Bash

برای مشاهده Serviceهایی که بیشترین زمان را گرفته‌اند:

Bash

systemd-analyze blame

Copy

systemd-analyze blame

Bash

مثلاً:

این خروجی نشان می‌دهد کدام Unitها بیشترین زمان را در فرآیند Boot مصرف کرده‌اند.

بعد می‌توان Log همان Service را بررسی کرد:

Bash

sudo journalctl -b -u plocate-updatedb.service

Copy

sudo journalctl -b -u plocate-updatedb.service

Bash

بررسی Critical Chain

برای مشاهده Dependency Chain مربوط به Boot:

Bash

systemd-analyze critical-chain

Copy

systemd-analyze critical-chain

Bash

این دستور می‌تواند نشان دهد کدام Unit باعث تأخیر Unitهای بعدی شده است.

در یک Boot کند، ترکیب:

Bash

systemd-analyze blame
systemd-analyze critical-chain
journalctl -b -u SERVICE

Copy

systemd-analyze blame
systemd-analyze critical-chain
journalctl -b -u SERVICE

Bash

معمولاً اطلاعات خوبی در اختیار Administrator قرار می‌دهد.

مثال عملی: SSH بعد از Reboot اجرا نشده است

ابتدا:

Bash

systemctl status sshd

Copy

systemctl status sshd

Bash

اگر failed باشد:

Bash

sudo journalctl -b -u sshd

Copy

sudo journalctl -b -u sshd

Bash

را اجرا کنید.

اگر Distribution نام Service را ssh استفاده می‌کند:

Bash

sudo journalctl -b -u ssh

Copy

sudo journalctl -b -u ssh

Bash

ممکن است خطایی مانند:

Bad configuration option
Could not load host key
Address already in use

مشاهده شود.

در این حالت علت واقعی از Log مشخص می‌شود و نباید بدون بررسی Configuration را به‌صورت تصادفی تغییر داد.

مثال عملی: MariaDB بعد از Reboot بالا نمی‌آید

بررسی وضعیت:

Bash

systemctl status mariadb

Copy

systemctl status mariadb

Bash

سپس:

Bash

sudo journalctl -b -u mariadb

Copy

sudo journalctl -b -u mariadb

Bash

برای Errorهای مهم:

Bash

sudo journalctl -b -u mariadb -p err

Copy

sudo journalctl -b -u mariadb -p err

Bash

موارد احتمالی می‌توانند شامل:

Disk full
Permission denied
InnoDB error
Corrupt file
Port already in use

باشند.

اگر /var یا / پر شده باشد:

Bash

df -h

Copy

df -h

Bash

را نیز بررسی کنید.

مقاله مرتبط:

آموزش کامل دستور df در لینوکس

مثال عملی: Filesystem بعد از Boot Read-only شده است

ابتدا Kernel Log را بررسی کنید:

Bash

sudo journalctl -k -b

Copy

sudo journalctl -k -b

Bash

سپس:

Bash

sudo journalctl -k -b \
  | grep -Ei "I/O error|read-only|filesystem|ext4|xfs"

Copy

sudo journalctl -k -b \
  | grep -Ei "I/O error|read-only|filesystem|ext4|xfs"

Bash

اگر Kernel به دلیل Disk Error فایل‌سیستم را Read-only کرده باشد، معمولاً پیام مرتبط در Kernel Log دیده می‌شود.

در چنین شرایطی فقط:

Bash

mount -o remount,rw

Copy

mount -o remount,rw

Bash

اجرا کردن بدون بررسی سلامت Storage راه‌حل مناسبی نیست؛ ابتدا باید علت Read-only شدن File System مشخص شود.

تفاوت `journalctl -b` و `/var/log/boot.log`

در برخی Distributionها ممکن است فایل:

/var/log/boot.log

نیز وجود داشته باشد.

اما journalctl -b معمولاً دید گسترده‌تری از Boot در سیستم‌های مبتنی بر systemd ارائه می‌دهد، زیرا می‌تواند پیام‌های Kernel، systemd Unitها و Serviceها را در همان Boot نشان دهد.

برای شناخت فایل‌های /var/log:

آموزش بررسی فایل‌های لاگ در /var/log لینوکس

تفاوت `journalctl -b` و `dmesg`

dmesg بیشتر برای مشاهده Kernel Ring Buffer استفاده می‌شود.

در مقابل journalctl -b می‌تواند علاوه بر Kernel Messageها، Logهای systemd و Serviceها را نیز نمایش دهد.

برای محدود کردن journalctl به Kernel از journalctl -k -b استفاده می‌کنیم.

بنابراین در Boot Troubleshooting معمولاً هر دو ابزار می‌توانند مفید باشند، اما journalctl -b دید جامع‌تری از Serviceها دارد.

اگر سیستم اصلاً Boot نمی‌شود چه؟

اگر سیستم آن‌قدر مشکل دارد که Shell یا SSH در دسترس نیست، طبیعتاً نمی‌توان مستقیماً journalctl -b را از داخل همان سیستم اجرا کرد.

در چنین شرایطی ممکن است نیاز باشد از:

Recovery Mode
Rescue Environment
Console Access
Live ISO
Provider Rescue System

استفاده شود.

سپس بسته به شرایط می‌توان Disk را Mount کرده و Journal Persistent را بررسی کرد.

بنابراین این مقاله بیشتر برای شرایطی مناسب است که سیستم حداقل به یک Shell قابل دسترسی رسیده باشد یا Journal آن از طریق محیط Rescue قابل خواندن باشد.

اشتباهات رایج

استفاده از `journalctl` بدون محدود کردن Boot

اگر مشکل مربوط به Reboot اخیر است journalctl -b معمولاً نتیجه مرتبط‌تری از journalctl دارد.

بررسی فقط Boot فعلی بعد از Crash

ممکن است علت Crash در journalctl -b -1 باشد.

فرض اینکه `-b -1` همیشه وجود دارد

اگر Journal Persistent نباشد، Log Boot قبلی ممکن است بعد از Reboot از بین رفته باشد.

جستجوی تصادفی کلمه Error در تمام Logها

ابتدا systemctl --failed را بررسی کرده و سپس Unit مشکل‌دار را با journalctl -b -u SERVICE بررسی کنید.

توجه نکردن به Kernel Log

مشکلات:

Disk
NIC
Filesystem
OOM
Driver
Hardware

اغلب در journalctl -k -b اطلاعات مهمی دارند.

فرض اینکه هر Warning علت اصلی است

ممکن است Warning مربوط به Componentی باشد که هیچ ارتباطی با مشکل فعلی ندارد.

بررسی نکردن زمان دقیق ایراد

در Journal بزرگ، استفاده از:

--since
--until

می‌تواند زمان عیب‌یابی را بسیار کمتر کند.

مسیر پیشنهادی برای عیب‌یابی Boot

یک روش عملی:

Server boots with an issue
        ↓
Check failed units
        ↓
systemctl --failed
        ↓
Check current boot errors
        ↓
journalctl -b -p err
        ↓
Check affected service
        ↓
journalctl -b -u SERVICE
        ↓
Check kernel if needed
        ↓
journalctl -k -b
        ↓
Check mounts / network / resources
        ↓
Fix the root cause

اگر Server بعد از Crash Reboot شده است:

Server rebooted
       ↓
journalctl --list-boots
       ↓
journalctl -b -1 -p err
       ↓
journalctl -k -b -1
       ↓
Check final messages before reboot

دستورات سریع Boot Troubleshooting

هدف	دستور
Boot فعلی	`journalctl -b`
Boot قبلی	`journalctl -b -1`
لیست Bootها	`journalctl --list-boots`
Errorهای Boot	`journalctl -b -p err`
Warning و بالاتر	`journalctl -b -p warning`
Kernel فعلی	`journalctl -k -b`
Kernel Boot قبلی	`journalctl -k -b -1`
Service خاص	`journalctl -b -u SERVICE`
Error یک Service	`journalctl -b -u SERVICE -p err`
آخر Journal	`journalctl -b -e`
از زمان مشخص	`journalctl -b --since "09:00"`
Unitهای Failed	`systemctl --failed`
زمان Boot	`systemd-analyze`
Serviceهای کند	`systemd-analyze blame`

مطالعه بیشتر

مقالات مرتبط در دانشنامه:

مستندات رسمی:

جمع‌بندی

برای بررسی اتفاقاتی که از زمان آخرین Boot رخ داده‌اند:

Bash

journalctl -b

Copy

journalctl -b

Bash

یکی از مهم‌ترین دستورات در سیستم‌های مبتنی بر systemd است. این گزینه Journal را به Boot انتخاب‌شده محدود می‌کند.

برای مشاهده فقط خطاهای مهم:

Bash

journalctl -b -p err

Copy

journalctl -b -p err

Bash

و برای بررسی یک Service مشخص:

Bash

journalctl -b -u SERVICE

Copy

journalctl -b -u SERVICE

Bash

استفاده می‌شود.

اگر Server بعد از Crash یا ایراد Reboot شده باشد، Boot قبلی اهمیت بیشتری دارد:

Bash

journalctl -b -1

Copy

journalctl -b -1

Bash

و برای Kernel:

Bash

journalctl -k -b -1

Copy

journalctl -k -b -1

Bash

اما مشاهده Bootهای قبلی به نگهداری Journal وابسته است و در صورت استفاده از Volatile Storage ممکن است Logها پس از Reboot باقی نمانند.

در عمل ترکیب:

Bash

systemctl --failed
journalctl -b -p err
journalctl -b -u SERVICE
journalctl -k -b

Copy

systemctl --failed
journalctl -b -p err
journalctl -b -u SERVICE
journalctl -k -b

Bash

یکی از بهترین نقاط شروع برای پیدا کردن علت خطاهای مرتبط با Boot در یک Linux Server است.

ش	ی	د	س	چ	پ	ج
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

journalctl -b؛ بررسی خطاهای Boot در لینوکس

دستور journalctl -b چه کاری انجام می‌دهد؟

چرا journalctl -b بهتر از journalctl ساده است؟

اجرای journalctl با sudo

خروج از journalctl

نمایش Log بدون Pager

مشاهده Bootهای ثبت‌شده

بررسی Boot قبلی

چرا journalctl -b -1 گاهی چیزی نمایش نمی‌دهد؟

بررسی Persistent Journal

نمایش فقط Errorهای Boot

بررسی Error و Warning

آیا هر Warning به معنی مشکل واقعی است؟

پیدا کردن Serviceهای Failed

بررسی Errorهای یک Service

مثال: Nginx بعد از Boot بالا نمی‌آید

بررسی Kernel Logهای Boot

بررسی Kernel Errorها

مثال: Disk یا Filesystem مشکل دارد

بررسی Mountهای ناموفق

بررسی /etc/fstab

بررسی Network بعد از Boot

پیدا کردن خطای DHCP

بررسی Boot قبلی بعد از Crash

مشاهده آخرین پیام‌های Boot قبلی

بررسی Out of Memory

محدود کردن Log به یک بازه زمانی

مشاهده Log از چند دقیقه اخیر

بررسی Boot با grep

بررسی یک Device مشخص

بررسی Dependency Failed

بررسی Boot Time

بررسی Critical Chain

مثال عملی: SSH بعد از Reboot اجرا نشده است

مثال عملی: MariaDB بعد از Reboot بالا نمی‌آید

مثال عملی: Filesystem بعد از Boot Read-only شده است

تفاوت journalctl -b و /var/log/boot.log

تفاوت journalctl -b و dmesg

اگر سیستم اصلاً Boot نمی‌شود چه؟

اشتباهات رایج

استفاده از journalctl بدون محدود کردن Boot

بررسی فقط Boot فعلی بعد از Crash

فرض اینکه -b -1 همیشه وجود دارد

جستجوی تصادفی کلمه Error در تمام Logها

توجه نکردن به Kernel Log

فرض اینکه هر Warning علت اصلی است

بررسی نکردن زمان دقیق ایراد

مسیر پیشنهادی برای عیب‌یابی Boot

دستورات سریع Boot Troubleshooting

مطالعه بیشتر

جمع‌بندی

نظرات خود را بنویسید... لغو پاسخ