E.g. I'm seeing this in /var/log/messages:

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

Is there a way to find out what caused the shutdown? E.g. was it run from console, or someone hit power button, etc.?

  • 2
    So this time a had some luck with /var/log/acpid: turned out the power button was hit. Any other ideas, where to look if acpid doesn't give a clue?
    – alex
    Commented Mar 21, 2011 at 19:20

12 Answers 12


Try the following commands:

Display list of last reboot entries: last reboot | less

Display list of last shutdown entries: last -x | less

or more precisely: last -x | grep shutdown | less

You won't know who did it however. If you want to know who did it, you will need to add a bit of code which means you'll know next time.

I've found this resource online. It might be useful to you:

How to find out who or what halted my system

  • 61
    Well, this doesn't tell me what caused the shutdown, only when it was done. Which I already know, see my question.
    – alex
    Commented Apr 5, 2011 at 6:22
  • 4
    more precisely last -x shutdown Commented Jun 10, 2013 at 5:49
  • 2
    The link is specifically to "How do I find out who or what halted my system (Old Sco Unix)?"
    – Wolfgang
    Commented Jun 20, 2017 at 19:14
  • What is last? How to install it?
    – Soerendip
    Commented Apr 22, 2020 at 17:59
  • 3
    Running last reboot showed me that I had a new kernel version every time after the sudden reboot. This led me to look at Unattended-Upgrade in /etc/apt/apt.conf.d/50unattended-upgrades and /etc/apt/apt.conf.d/99custom-unattended-upgrades. See my answer here for more details: askubuntu.com/a/1261057/119592
    – Zoltán
    Commented Jul 22, 2020 at 9:12


Use these 2 commands and keep reading for more information.
last -x | head | tac

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'

1) Regarding the output of last -x command

Run this command* and compare the output to the examples below:

last -x | head | tac

Normal shutdown examples

A normal shutdown and power-up looks like this (note that you have a shutdown event and then a system boot event):

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

In some cases you may see this (note that there is no line about the shutdown but the system was at runlevel 0 which is the "halt state"):

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

Unexpected shutdown examples

An unexpected shutdown from power loss looks like this (note that you have a system boot event without a prior system shutdown event):

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

2) Regarding the logs in /var/log/

A bash command to filter the most interesting log messages is this:

grep -iva ': 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'

When an unexpected power off or hardware failure occurs the filesystems will not be properly unmounted so in the next boot you may get logs like this:

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

When the system powers off because user pressed the power button you get logs like this:

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

Only when the system shuts down orderly you get logs like this:

rsyslogd: ... exiting on signal 15

When the system shuts down due to overheating you get logs like this:

critical temperature reached...,shutting down

If you have a UPS and running a daemon to monitor power and shutdown you should obviously check its logs (NUT logs on /var/log/messages but apcupsd logs on /var/log/apcupsd*)


*: Here's the description of last from its man page:

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

We use head to keep the latest 10 events and we use tac to invert the ordering so that we don't get confused by the fact that last prints from most recent to least recent event.

  • 3
    Thanks! I needed a slight modification for an Ubuntu system: grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' /var/log/auth.log /var/log/syslog | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'
    – moo
    Commented Feb 11, 2021 at 3:50
  • exit on signal 15 is not available in the buster OS's syslog. How to find the same in buster?
    – vishnu m c
    Commented May 26, 2021 at 11:49
  • You may want to adjust the grep example to use --text in the argument or you may get a 'binary file matches' message instead of textual matches.
    – Brian
    Commented Oct 20, 2023 at 15:13
  • @Brian thanks for the suggestion -- I've added the argument
    – ndemou
    Commented Oct 23, 2023 at 12:31

Only root privileged programs can gracefully shutdown a system. So when a system shuts down in a normal way, it is either a user with root privileges or an acpi script. In both cases you can find out by checking the logs. An acpi shutdown can be caused by power button press, overheating or low battery (laptop). I forgot the third reason, UPS software when power supply fails, which will send an alert anyway.

Recently I had a system that started repeatedly to power off ungracefully, turned out that it was overheating and the mobo was configured to just power off early. The system didn't have a chance to save logs, but fortunately monitoring the system's temperature showed it was starting to increase just before powering off.

So if it is a normal shutdown it will be logged, if it is an intrusion... good luck, and if it is a cold shutdown your best chance to know is to control and monitor its environment.

  • 12
    In both cases you can find out by checking the logs. .... which log files should I check? Commented May 24, 2021 at 8:59
  • 2
    journalctl, /var/log/syslog, /var/log/messages
    – Dagelf
    Commented Jan 20, 2022 at 9:32

Some possible log files to explore: (found a Ubuntu system, but I would hope that they're present on most Linux/Unix systems)

/var/log/syslog (will be pretty full and may be harder to browse)

Again, these log files are present on a Ubuntu system, so filenames may be different. The tail command is your friend.


Simplify using last displaying the system shutdown entries and run level changes and filtering on shutdown and reboot:

last -x shutdown reboot

Not fully satisfying

I had a similar need on a Debian 7.8 and observe that basically there's no clear and explicit message in log, which is a little surprising.

Grep through /var/log would tell the time the machine was shut down, show proper daemons shutdown, etc, but not the initial reason.

shutdown[25861]: shutting down for system halt

The other solutions mentioned (last -x) did not help much.

Looking how it works

Reading /etc/acpi/powerbtn-acpi-support.sh which includes:

if [ -x /etc/acpi/powerbtn.sh ] ; then
    # Compatibility with old config script from acpid package
elif [ -x /etc/acpi/powerbtn.sh.dpkg-bak ] ; then
        # Compatibility with old config script from acpid package
    # which is still around because it was changed by the admin
    # Normal handling.
    /sbin/shutdown -h -P now "Power button pressed"

Notice that an explicit text is given as parameter of the shutdown command. I would expect that string to be logged automatically by the shutdown program.

Adjusting for better logs

Anyway, to get an explicit message I put the text below (as root) in a newly created /etc/acpi/powerbtn.sh made executable with chmod a+x /etc/acpi/powerbtn.sh

logger in /etc/acpi/powerbtn.sh, presumably "Power button pressed"
    /sbin/shutdown -h -P now "Power button pressed"

Doing it this way will probably make a longer lasting change than modifying /etc/acpi/powerbtn-acpi-support.sh. The latter option would probably lose its effect on next upgrade of package acpi-support-base.

Notice than Ubuntu 14.04 does it differently (/etc/acpi/powerbtn.sh already exists with different content from acpid package). Also, Debian 8 probably does it differently. Feel free to offer variants.


And now when the power button is pressed, a line like below appears in /var/log/messages, /var/log/syslog and /var/log/user.log:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

Now that's an explicit message in the log.

  • Thanks to @Bielecki for suggesting to consider installing acpi-support-base and acpid packages. I haven't tested myself. Can you elaborate on which distribution and version it yields benefits? Commented Jan 8, 2019 at 12:40
  • Nice solution. What would be required to get a patch out there to get the fix into the distribution?
    – Atif
    Commented Jan 8, 2020 at 17:54

I have just a clumsy idea, but maybe it works for you: enter the command last and check out the login informations for all of the users. then, filter th users with the permission required for halt that had been logged in at that moment. then check out their .bash_history file to see if they have entered halt or not.


In my case I had a problem of overheating and found the log in /var/log/syslog by a 'grep shut *' in /var/log folder.

The error logged was this:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down

Just chip in that on my KVM VM (where I wondered whether a host reboot did a clean shutdown of guests), I found what I needed in /var/log/auth.log (in addition to last -x shutdown showing the same). There these lines showed up:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -x shows these lines, notice that they're being printed in most-recent-first order (i.e. read the last line first, and then go up), but due to the clock reset (23:56 before boot, 23:55 after) also evident in the previous lines, the order seems a little bewildering:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

For my part, checking that guests get cleanly shut down when host is booted, I could also just log into (ssh) one of the guests, and stay there when I boot the host, getting these lines in the terminal:

Broadcast message from root@Web
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.
cat /usr/adm/syslog

in my case it was the ups software shutting down the server.


alias the shutdown to a script
the script must give all the parameters, etc to the original shutdown executable
BUT: the script must log those this

  • 3
    The shutdown script does this already (last -x)
    – forcefsck
    Commented Apr 2, 2011 at 21:33

For me, logs revealed nothing, temp monitoring did. I realized, in summertime, when I start some heavy computer analysis, I had to put the laptop in the fridge, heh.

Monitor temp by adding an alias to ~/.bashrc:

alias monitortemp='while true; do { date & sensors; } >> temp.log; sleep 10; done'

and then type monitortemp in the shell. Output in the file temp.log

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .