How to Find Out Who Rebooted Your Ubuntu Server (Step-by-Step Guide)

Short summary: Use built-in Linux tools (`who`, `last`, `journalctl`, `/var/log/auth.log`) and optional audit logs to identify when, why, and who triggered a server reboot.

Quick Commands Cheat Sheet


# 1. Last boot time
who -b

# 2. Reboot history
last reboot

# 3. Previous boot shutdown/reboot events
journalctl -b -1 | grep -iE "reboot|shutdown"

# 4. Find who triggered the reboot
grep -i "reboot" /var/log/auth.log
journalctl -b -1 -u systemd-logind

# 5. See user’s last commands (replace USERNAME)
sudo cat /home/USERNAME/.bash_history | tail -n 20

# 6. Audit logs (if auditd is installed)
ausearch -m system_boot,system_shutdown --start today

Introduction

Unexpected reboots cause downtime and confusion. This guide helps Linux admins, DevOps engineers, and hosting providers quickly determine when the server rebooted, whether it was intentional or a crash, and which user or process initiated the reboot.

1. Check Last Boot Time

Run:

who -b

Example output:

system boot  2025-08-11 13:53

This gives the exact date and time of the last system start.

2. View Reboot History

Use:

last reboot

This reads from /var/log/wtmp and lists past reboot records.

3. Inspect Previous Boot Logs

To see shutdown/reboot messages from the previous boot:

journalctl -b -1 | grep -iE "reboot|shutdown"

If you see systemd-reboot.service: Deactivated successfully., the reboot was clean and likely intentional.

4. Identify Which User Triggered the Reboot

Search authentication logs for reboot activity:

grep -i "reboot" /var/log/auth.log
journalctl -b -1 -u systemd-logind

Example lines to look for:

Aug 11 13:51:08 server systemd-logind[989]: New session 1745 of user adminuser.
Aug 11 13:51:29 server systemd-logind[989]: System is rebooting.

Here, adminuser was logged in just before the reboot — likely the actor who initiated it.

5. See the Exact Command Used

Check the user’s shell history (replace USERNAME):

sudo cat /home/USERNAME/.bash_history | tail -n 20

If the user had HISTTIMEFORMAT enabled, the history may include timestamps.

6. Dig Deeper with Audit Logs

If auditd is enabled, use:

ausearch -m system_boot,system_shutdown --start today

This can show the exact process (with PID) and the syscall that triggered the shutdown or reboot.

FAQ

How to determine if a reboot was caused by a crash or kernel panic?

Check kernel messages from the previous boot:

journalctl -k -b -1

Look for “panic”, oops strings, or stack traces that indicate a kernel crash.

Can I find a reboot triggered via SSH?

Yes. Authentication logs and systemd-logind entries will show the SSH session and user associated with the reboot.

How to prevent unauthorized reboots?

Limit sudo privileges, require stronger authentication, and enable auditd so commands like shutdown and reboot are recorded centrally.

Conclusion

Using these commands you can quickly answer three key questions after any reboot:

When did the reboot occur? — who -b
Why did it happen? — journalctl -b -1
Who triggered it? — /var/log/auth.log and systemd-logind

Armed with this information you can respond to incidents faster and lock down your servers if reboots are unauthorized.

More troubleshooting guides:

Note: Replace the internal links above with the actual permalinks on your site and update the canonical & OG image URLs to match your blog assets.