Det hender ofte at et Linux-system uventet starter på nytt, uten at årsaken er umiddelbart klar. Å identifisere og løse årsaken til slike omstarter er viktig for å unngå gjentakelse av problemet og forhindre uplanlagt nedetid.
Det finnes flere metoder for å spore opp hva som utløste en omstart. I denne artikkelen vil vi se nærmere på disse metodene, og hvordan du kan bruke tilgjengelige verktøy og logger i et Linux-system for å feilsøke slike situasjoner.
Undersøk omstartstidspunkt
Du kan finne ut når systemet sist startet ved hjelp av kommandoene `who` og `last`:
$ who -b system boot 2021-02-13 20:51 $ last -x | head | tac abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02) reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58) runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08) abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07) reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49) runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46) abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46) reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03) runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02) abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in $
Gjennomgå systemmeldinger
Du kan sammenholde omstartstidspunktet med systemmeldinger for å få mer informasjon.
På CentOS/RHEL-systemer finner du loggene i `/var/log/messages`, mens de for Ubuntu/Debian-systemer finnes i `/var/log/syslog`. Du kan bruke `tail`-kommandoen eller en tekstredigerer for å filtrere eller finne spesifikke data.
Som man kan se i eksemplene nedenfor, indikerer oppføringer som disse at en administrator eller rotbruker har initiert en avslutning eller omstart. Meldingene kan variere avhengig av operativsystem og hvordan omstarten ble utløst, men systemloggene vil alltid gi nyttig informasjon, selv om de kanskje ikke alltid gir en konkret årsak.
Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5 Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123 Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root. Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root. Feb 13 20:04:09 centos7vm systemd-logind: System is powering down. Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket. Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.
Her er et eksempel på en kommando du kan bruke for å filtrere systemlogger:
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'
Husk at hendelsene som fanges opp ikke alltid er spesifikke. Se alltid etter hendelser som gir indikasjoner på advarsler eller feil som kan ha ført til at systemet slo seg av eller krasjet.
Sjekk revisjonslogger
For systemer som bruker revisjon, er det nyttig å sjekke forskjellige hendelser ved hjelp av `ausearch`-verktøyet. Bruk følgende kommando for å se de to siste oppføringene fra revisjonsloggene:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Dette vil vise de to siste avslutningene eller omstartene. Hvis utdataene viser en `SYSTEM_SHUTDOWN` etterfulgt av en `SYSTEM_BOOT`, er alt som regel i orden. Men hvis det vises to `SYSTEM_BOOT`-linjer på rad, eller bare en enkelt `SYSTEM_BOOT`-linje, har systemet sannsynligvis ikke blitt avsluttet på en kontrollert måte. En normal utgang ser omtrent slik ut:
$ 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' $
Utdataene nedenfor viser to påfølgende `SYSTEM_BOOT`-meldinger, noe som kan indikere en uventet avslutning, selv om dette bør bekreftes med systemlogger:
$ 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' $
Analyser systemd-journal
Du bør ha en vedvarende systemd-journal for å lagre loggene på disk. Hvis ikke, vil loggene ikke være tilgjengelige etter en omstart. Du kan enten endre konfigurasjonsfilen `/etc/systemd/journald.conf` eller opprette katalogen med følgende kommandoer:
$ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald
Etter dette kan du eventuelt starte systemet på nytt for å loggføre mer enn én omstartsoppføring i journalen, men det er ikke nødvendig.
Bruk følgende kommando for å liste loggede oppstarter fra journalen:
$ journalctl --list-boots
Her er et eksempel fra en server:
$ journalctl --list-boots -15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST -14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST -13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST -12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST -11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST -10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST -9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST -8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST -7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST -6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST -5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST -4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST -3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST -2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST -1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST 0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST
Som du ser, har det vært flere oppstarter. For å analysere en spesifikk omstart, bruk:
$ journalctl -b {num} -n
Her vil `{num}` være indeksen gitt i `journalctl –list-boots`-kommandoen i den første kolonnen.
$ journalctl -b -1 -n -- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. -- Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step. Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down. Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices. Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped
I utdataene over kan du se meldinger som er loggført i journalen og identifisere eventuelle uregelmessigheter.
Konklusjon
Det er ikke alltid mulig å fastslå årsaken til en Linux-omstart med en enkelt kommando eller fra én loggfil. Derfor er det nyttig å kjenne til kommandoer og logger som fanger opp systemrelaterte hendelser, noe som kan forkorte tiden som trengs for å finne årsaken.
Eksemplene ovenfor gir deg et utgangspunkt for feilsøkingen. Ved å kombinere disse verktøyene og loggene kan du være trygg på at du vet hva som har skjedd og hvorfor systemet har startet på nytt.
Neste steg er å se på noen enkle overvåkingsverktøy for Linux.