[PATCH v2] reboot: log the task that requested a reboot or shutdown

[PATCH v2] reboot: log the task that requested a reboot or shutdown

[Bradley Morgan]

When a machine reboots or powers off, the kernel log records what
happened but not who asked for it.  The reboot syscall throws the
caller identity away, and reconstructing it afterwards from userspace
logs is unreliable and more likely than not impossible.
"What made this reboot?" is a question every fleet operator has had to
answer with guesswork.

Log the comm and pid of the calling task in the reboot syscall, once
the requested command is committed and can no longer fail, e.g:

  reboot: initiated by systemd-shutdow[1]
  reboot: Restarting system

The existing "Restarting system", "System halted" and "Power down"
lines are left untouched, so anything parsing dmesg today keeps
working. The two ctrl alt del toggle commands are excluded so init
setting the mode does not add a line to dmesg on every boot.

Signed-off-by: Bradley Morgan <include@grrlz.net>
---
 kernel/reboot.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/kernel/reboot.c b/kernel/reboot.c
index c10ac6a0200d..ecf9535078f5 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -718,6 +718,12 @@ EXPORT_SYMBOL_GPL(kernel_power_off);
 
 DEFINE_MUTEX(system_transition_mutex);
 
+static void reboot_log_initiator(void)
+{
+	pr_info("initiated by %s[%d]\n",
+		current->comm, task_pid_nr(current));
+}
+
 /*
  * Reboot system call: for obvious reasons only root may call it,
  * and even root needs to set up some magic numbers in the registers
@@ -765,6 +771,7 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 	mutex_lock(&system_transition_mutex);
 	switch (cmd) {
 	case LINUX_REBOOT_CMD_RESTART:
+		reboot_log_initiator();
 		kernel_restart(NULL);
 		break;
 
@@ -777,11 +784,13 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		break;
 
 	case LINUX_REBOOT_CMD_HALT:
+		reboot_log_initiator();
 		kernel_halt();
 		/* machine_halt() was expected to not return. */
 		make_task_dead(SIGKILL);
 
 	case LINUX_REBOOT_CMD_POWER_OFF:
+		reboot_log_initiator();
 		kernel_power_off();
 		/* machine_power_off() was expected to not return. */
 		make_task_dead(SIGKILL);
@@ -795,6 +804,7 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		}
 		buffer[sizeof(buffer) - 1] = '\0';
 
+		reboot_log_initiator();
 		kernel_restart(buffer);
 		break;
 
-- 
2.53.0

Re: [PATCH v2] reboot: log the task that requested a reboot or shutdown

[Andrew Morton]

On Sun, 19 Jul 2026 16:09:38 +0000 Bradley Morgan <include@grrlz.net> wrote:

> When a machine reboots or powers off, the kernel log records what
> happened but not who asked for it.  The reboot syscall throws the
> caller identity away, and reconstructing it afterwards from userspace
> logs is unreliable and more likely than not impossible.
> "What made this reboot?" is a question every fleet operator has had to
> answer with guesswork.

There's a need for this?  May I ask your source for this information?

> Log the comm and pid of the calling task in the reboot syscall, once
> the requested command is committed and can no longer fail, e.g:
> 
>   reboot: initiated by systemd-shutdow[1]
>   reboot: Restarting system

I can see it might be useful.

> The existing "Restarting system", "System halted" and "Power down"
> lines are left untouched, so anything parsing dmesg today keeps
> working. The two ctrl alt del toggle commands are excluded so init
> setting the mode does not add a line to dmesg on every boot.

Perhaps kexec and swsusp would benefit from the same treatment. 
Perhaps add the relevant maintainers to cc and seek their input?

Re: [PATCH v2] reboot: log the task that requested a reboot or shutdown

[Bradley Morgan]

On July 20, 2026 7:15:40 AM GMT+01:00, Andrew Morton
<akpm@linux-foundation.org> wrote:
>On Sun, 19 Jul 2026 16:09:38 +0000 Bradley Morgan <include@grrlz.net>
>wrote:
>
>> When a machine reboots or powers off, the kernel log records what
>> happened but not who asked for it.  The reboot syscall throws the
>> caller identity away, and reconstructing it afterwards from userspace
>> logs is unreliable and more likely than not impossible.
>> "What made this reboot?" is a question every fleet operator has had to
>> answer with guesswork.
>
>There's a need for this?  May I ask your source for this information?

I had no source, at the time, I just thought it'd be obviously useful.

Now I did some research, I found this tool:
https://docs.memfault.com/docs/linux/reboot-reason-tracking



>> Log the comm and pid of the calling task in the reboot syscall, once
>> the requested command is committed and can no longer fail, e.g:
>> 
>>   reboot: initiated by systemd-shutdow[1]
>>   reboot: Restarting system
>
>I can see it might be useful.

Thanks

>> The existing "Restarting system", "System halted" and "Power down"
>> lines are left untouched, so anything parsing dmesg today keeps
>> working. The two ctrl alt del toggle commands are excluded so init
>> setting the mode does not add a line to dmesg on every boot.
>
>Perhaps kexec and suswp would benefit from the same treatment. 
>Perhaps add the relevant maintainers to cc and seek their input?

kexec is definitely gonna be able to use this, hibernation has /sys/power
Entry points. So not sure about them

>
>

Thanks!