Skip to content
Related Articles

Related Articles

Improve Article

How to determine the cause for a restart in Kali Linux?

  • Last Updated : 18 Jul, 2021

We can figure out what caused the reboot through a few different methods. We’ll go through those methods in this post and use accessible programs and logs on a Linux system to diagnose such issues.

It’s not uncommon to discover that a Linux system has restarted unexpectedly or for no apparent reason. Finding and fixing the core cause might help prevent future problems and unexpected downtime.

Examine the systemd journal

If you don’t have a persistent systemd-journal, you won’t be able to retain a persistent journal on disc, and your logs will be lost when you reboot. You may do this by editing /etc/systemd/journald.conf or manually creating the directory using the instructions below:

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

After that, you can reboot the machine if you want to record more than one rebooted entry in the journal, although it’s not needed.



To get a list of logged boots from the journal, use the command below:

journalctl --list-boots

As you can see, the listing is for a number of boots. Use the following command to go further into a specific reboot:

journalctl -b {num} -n

Examine the System Messages

You may also connect system messages with the reboot you wish to diagnose.

The logs are located in /var/log/messages on CentOS/RHEL systems. It is logged into /var/log/Syslog on Ubuntu/Debian systems. To filter out or discover specific data, just use the tail command or your favorite text editor.

Such entries indicate a shutdown/reboot triggered by an administrator or root user, as can be seen in the logs below. These messages differ depending on the OS and how the reboot/shutdown is initiated, but checking through system logs will always provide helpful information, even if it isn’t always precise enough to pinpoint the reason.

nano  /var/log/syslog



The following is an example of a command that may be used to filter out system logs:

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’

It’s possible that captured events aren’t always specific. Always look for warnings or problems that might cause the system to shut down or crash.

Examine the Reboot Time

You may use the who and last commands to see when the system was rebooted.

who -b

last -x | head | tac

Check the audited logs

It’s a fantastic location to inspect various events using the ausearch tool for systems using auditd. To check the last two items in audit logs, use the command below.



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

The two most recent shutdowns or reboots will be reported. Everything should be OK if this reports an SYSTEM_SHUTDOWN followed by an SYSTEM_BOOT. If it returns two or more SYSTEM_BOOT lines in a row or only one SYSTEM_BOOT line, then the system does not shut down gracefully. The following is an example of a typical output:

—-

type=SYSTEM_SHUTDOWN msg=audit(Monday 28 June 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(Monday 28 June 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’

Two successive SYSTEM_BOOT messages are listed in the above output, which might suggest an ungraceful shutdown if connected with system logs.

Conclusion

A single command or a single log file may not always be enough to determine the reason for a Linux reboot. As a result, knowing the commands and logs that record system-related events is always useful and can cut down on the time it takes to discover the underlying cause.

The samples above might help you get started with the troubleshooting. You may be sure to know what happened and how your system restarted if you use a mix of such tools and logs.

My Personal Notes arrow_drop_up
Recommended Articles
Page :