Linux-da reboot səbəblərinin araşdırılması

Bəzən Linux-da planlanmamış və ya qeyri-müəyyən səbəblərdən reboot (yenidən başlama) prosesi gedə bilər. Səbəbin araşdırılaraq aradan qaldırılması, gələcəkdə nəzərdə tutulmayan fasilələrdən yayınmağa imkan verəcək.

Yenidən başlamanın səbəbini araşdırmaq üçün bir neçə üsul var. Bu materialda Linux-da olan alətlərdən və qeydiyyat jurnallarında istifadə etməklə problemin araşdırılması yollarından danışacağıq.

Reboot vaxtının müəyyən edilməsi

Sistemin nə zaman yenidən başladığını yoxlamaq üçün who və last komandalarından istifadə etmək olar.

Sistem jurnallarının yoxlanılması

Bununla yanaşı, yenidən başlama prosesisnin baş verdiyi vaxtı sistem məlumatları ilə müqayisə edərək diaqnostika etmək olar.

CentOS/RHEL bazalı Linux-da /var/log/messages yazmaqla sistem jurnallarında baş verlənlərə baxmaq olar. Ubuntu/Debian əsaslı sistemlərdə isə bu məlumatlar /var/log/syslog faylında yerləşir. Nəticələri filtrləmək və ya konkret məlumatları axtarmaq üçün tail komandasından, yaxud da bəyəndiyiniz mətn redaktorundan istifadə edə bilərsiniz.

Aşağıdakı şəkildə olan məlumatlarda görünür ki, sistemin sönməsi /yenidən başlaması root, yaxud da administrator səlahiyyətli istifadəçi tərəfindən həyata keçirilib. Əməliyyat sisteminin (ƏS) növündən, sistemin sönməsi/yenidən başlaması üsulundan asılı olaraq bu məlumatlar dəyişə bilər. Lakin hər bir halda sistem jurnalları sizə faydalı informasiya verə bilər. Amma problemin səbəbini araşdırmaq üçün onlar heç də hər zaman kifayət etmir.

Göstərilən komanda sistem jurnallarının filtrlənməsi üçün istifadə oluna biləcək komandalardan biridir:

sudo grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \ /var/log/messages /var/log/syslog /var/log/apcupsd* \ | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

Qeydə alınmış hadisələr hər zaman konkret olmur. Ona görə də, araşdırma zamanı daha çox sistemin sönməsinə səbəb ola biləcək xəbərdarlıq və səhvlər haqqında məlumatlara fikir vermək lazımdır.

auditd jurnalının yoxlanılması

auditd istifadə edən sistemlərdə baş vermiş hadisələrin araşdırılması üçün bu ən yaxşı başlanğıc nöqtəsidir. Bu işdə ausearch köməyə çatır. Məsələn audit jurnallarından son iki hadisə haqqında qeydləri əldə etmək üçün aşağıdakı komandadan istifadə etmək olar.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

Komandanı daxil edəndən sonra son iki sönmə və ya yenidən başlama haqqında məlumat əks olunacaq. Əgər qeydlərdə SYSTEM_SHUTDOWN, ardınca isə SYSTEM_BOOT gəlirsə, deməli hər şey qaydasındadır. Əgər ardıcıl olaraq iki dəfə SYSTEM_BOOT və ya təkcə SYSTEM_BOOT yazılıbsa, deməli sistem nasazlıq səbəbindən sönüb və ya reboot olub. Sistemin normal işi zamanı qaytarılan cavab aşağıdakı kimi olmalıdır.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
---
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
---
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

Növbəti nümunədə isə ard-arda iki SYSTEM_BOOT tipli ismarış çıxıb ki, bu da sistemin nasazlıq səbəbindən sönməsinə işarədir. Amma hər bir halda sistem jurnalının məlumatları ilə tutuşdurmaq lazımdır.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
---
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
---
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

systemd jurnalının analizi

Sistemin generasiya etdiyi loqları kompüterin yaddaşında həmişəlik saxlamaq üçün daimi sistem jurnalı lazımdır, əks halda loqlar hər dəfə silinəcək. Bunun üçün ya /etc/systemd/journald.conf faylında dəyişiklik edilməlidir, ya da aşağıda göstərildiyi kimi ayrıca kataloq yaradılmalıdır:

$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald

Bundan sonra yoxlamaq üçün sistemi yenidən başlatmaq olar, amma adətən zərurət olmur.

Növbəti komanda isə həmin jurnaldan sistemin yüklənməsi haqqında qeydləri əldə etməyə imkan verir.

$ journalctl --list-boots

Məsələn, aşağıdakı kimi:

Şəkildə göründüyü kimi, sistemin yüklənməsi haqqında bir neçə qeyd var. Növbəti mərhələ üçün aşağıdakı komandadan yararlanmaq olar:

$ journalctl -b {num} –n

Burada{num} journalctl --list-boots komandası nəticəsində çıxan məlumatda birinci sütündakı indeksdir:

Beləliklə, jurnalda qeydə alınmış məlumatlara nəzər salaraq mövcud anomallıqları izləmək mümküdür.

Yekun

Sistemin hansı səbəbdən söndüyünü və ya yenidən başladığını müəyyənləşdirmək üçün bir komanda, yaxud da təkcə sistem jurnalı yetərli deyil. Bu səbəbdən sistemlə əlaqəli hadisələri qeydə alan komanda və jurnalları haqqında bilmək vacibdir.

Yuxarıdakı nümunələr nasazlıqların araşdırılıb, aradan qaldırılmasına imkan yaradır. Belə alət və jurnalların kombinasiyası sayəsində sistemində nəyin, hansı səbəbdən baş verdiyini aydınlaşdırmaq olar.

Mənbə: Geekflare