İşletim sisteminden bağımsız olarak tüm bilgisayar sistemlerindeki tüm kapanmaların düzgün (graceful) kapanma olması gerekir. Yarım kalan bir yazma işlemi, kapanmamış dosyalar vs bir sonraki açılışta en basitinden birkaç hata ve disk denetlemesinden, geri getirilemez veri kayıpları ve sistemin tekrar kurulmasına kadar sorunları getirebilir.
Beklenmeyen kapanmalar neler olabilir? Bir sistem bileşeni yüzünden sistemin tekrar başlaması (veya sadece kapanması), güç kaybı sebebiyle sistemin kapanması.
last komutuyla sistemdeki açılış ve kapanış olaylarının listesini alabiliriz. Şu kaynakta belirtildiği gibi
$ last -Fxn2 shutdown reboot
-F : Uzun tarih formatı kullan
-x : Kapanma ve çalışma seviyesi değişikliklerini de göster
-n2: En son 2 olayı listele
komudu normal şartlar altında bir kapanışı takip eden bir açılış listelemeli. Eğer normal bir kapanma yoksa iki açılış olayı ile karşı karşıya kalabiliriz. Aşağıdaki çıktıya bakarsak
reboot system boot 5.9.10-200.fc33. Sun Nov 29 17:09:18 2020 still running
reboot system boot 5.9.10-200.fc33. Sun Nov 29 16:10:37 2020 still running
16:10'daki açılış da hala "still running" olarak gözüküyor, 17:09'daki açılış da. Bu arada bir beklenmeyen bir kapanış olmuş. Normal bir kapanış ve açılış sonrasında şu gözükür:
reboot system boot 5.9.10-200.fc33. Sun Nov 29 16:10:37 2020 still running
shutdown system down 5.9.10-200.fc33. Sun Nov 29 01:58:33 2020 - Sun Nov 29 16:10:37 2020 (14:12)
Aynı kaynakta alternatif olarak ausearch aracının kullanılmasından da bahsedilmiş. Örneğin
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
benim normal olarak kapanmayan sistemimde şu sonuçları verdi:
Option ENRICHED not found - line 9
NOTE - using built-in logs: /var/log/audit/audit.log
----
type=SYSTEM_BOOT msg=audit(29-11-2020 13:10:59.324:106) : pid=778 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(29-11-2020 14:09:31.491:105) : pid=793 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'
Normal bir kapanış sonrası ise şuna benzer bir kapanış ve sonrasında bir açılış içeren bir çıktı üretmesi gerekirdi:
---
type=SYSTEM_SHUTDOWN msg=audit(29-11-2020 01:58:33.647:1688) : pid=19324 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(29-11-2020 13:10:59.324:106) : pid=778 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'
Bu iki durumda da 2 değil 1 satır veri görünüyorsa loglarda bir kalıcılık yoktur, ya da yeterli süre açık kalan bir sistemin son açılış sonrasındaki kayıtları silinmiş olabilir.
2026-07-07 Ek: Başka bir durumda kapanıp tekrar açılmış bir sistemin last reboot kayıtlarında şöyle bir satır vardı:
reboot system boot 6.9.12-200.fc40* Mon Feb 23 11:27:20 2026 - Tue Apr 28 10:22:17 2026 (63+22:54)
reboot system boot 6.9.12-200.fc40. Sat Feb 21 14:18:35 2026 - crash (1+21:08)
Burada beklenmeyen bir kapanma olmuş gibi gözüküyor. Gerçekten de journalctl kayıtlarında ani bir kesinti var mı diye kontrol etmek istedim. Paralel olarak journalctl --list-boots ile kapanan boot işleminin -8. işlem olduğunu gördüm. Ayrıca bu kayıtlarda sistemin en son 11:21:50'ye kadar kayıt düştüğü de gözüküyor. Bundan 5 dakika sonra sistem yeniden başlamış. Ne olduysa buranın önünde arkasında bir yerlerde olmuş.
-8 c4e13d6cdabd47e7a3c15dcc2c32d482 Sat 2026-02-21 14:18:28 +03 Mon 2026-02-23 11:21:50 +03
-7 cd47afdf66524011a81b7654a28c21bf Mon 2026-02-23 11:27:14 +03 Tue 2026-04-28 10:22:19 +03
ve --until parameteresini bir sonraki açılıştan birkaç dakika sonrası seçtim. -8 boot işlemi için 11:27'den sonra bir işlem yok, bunlar -7 boot işlemi için. Onun için bu güvenli, bir sonraki boot işleminin kayıtları araya girmeyecek.
journalctl -b -9 --since "2026-02-23 11:00" --until "2026-02-23 11:30"
Burada sadece sysstat-collect.service hizmetine ait devreye girdi ve devreden çıktı gibi kayıtlar var, kapanışa ait bir şey yok ve kayıtlar çok keskin bir şekilde son bulmuş.
Daha ilginç bir çözüm olarak bizim sistemimize özel bir hizmet birimi oluşturmamız önerilmiş. Sadece kapanışta çalılştırılacak /etc/systemd/system/set_gracefulshutdown.service dosyasının içeriği olarak şunlar önerilmiş:
ile bunlar etkinleştirilmiş. Bu hizmet birimi kapanışta /root/graceful_shutdown dosyası oluşturacak. Ayrıca bir de açılışlarda çalışacak /etc/systemd/system/check_graceful.service hizmet birimi önerilmiş:
komutu ile önceki kapanmanın normal olup olmadığını anlayuabiliriz.
En son olarak bir de journalctl ile durum kontorlü önerilmiş.
$ sudo journalctl -b -1 -n
Bu komut, bir önceki boot'ta (-b -1) en son 10 (-n parametresinin varsayılanı 10) kaydını görüntüler. Normal olarak aşağıdakine benzer bir çıktı olması gerekir:
Eyl 06 13:46:58 archbox systemd[1]: Reached target System Shutdown.Eyl 06 13:46:58 archbox systemd[1]: Reached target Late Shutdown Services.
Eyl 06 13:46:58 archbox systemd[1]: systemd-reboot.service: Deactivated successfully.
Eyl 06 13:46:58 archbox systemd[1]: Finished System Reboot.
Eyl 06 13:46:58 archbox systemd[1]: Shutting down.
Eyl 06 13:46:58 archbox systemd-shutdown[1]: Syncing filesystems and block devices.
Eyl 06 13:46:58 archbox systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Eyl 06 13:46:58 archbox systemd-journald[218]: Received SIGTERM from PID 1 (systemd-shutdow).
Eyl 06 13:46:58 archbox systemd-journald[218]: Journal stopped
Böyle bir durumda aranılan satırlar başarılı olarak kapanmanın ve gerçekleştiğini gösteren (Reached System Shutdown, Finished System Reboot/Shutdown gibi) satırlar ve Journal stopped mesajları olabilir. Benim sistemimde bol hatalı bir çıktı üretti, beklenmeyen kapanmanın göstergesi olarak.
Hiç yorum yok:
Yorum Gönder