[PATCH v2 0/3] reboot: log the task that initiated

[PATCH v2 0/3] reboot: log the task that initiated

[Bradley Morgan]

When a machine reboots, powers off, kexecs or hibernates, the kernel
log records what happened but not who asked for it. This series logs
the comm and pid of the initiating task once the transition is
committed:

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

Patch 1 covers the restart, halt and power off commands of the
reboot syscall. Patches 2 and 3 give kexec and the hibernation power
down the same treatment at their own points of no return, as
suggested in the v1 review [1]. The kexec and PM maintainers are on
cc for their input on those two.

v1 -> v2:
- Reworded the justification in patch 1: dropped the fleet operator
  claim and spelled out the concrete gap in userspace logging
- New patch 2: log the initiator for kexec reboots
- New patch 3: log the initiator for the hibernation power down
- Added the kexec and PM maintainers and lists to cc

[1] https://lore.kernel.org/all/20260719160938.3692-1-include@grrlz.net/

Bradley Morgan (3):
  reboot: log the task that initiated the reboot
  kexec: log the task that initiated the kexec reboot
  PM: hibernate: log the task that initiated the power down

 include/linux/reboot.h   |  1 +
 kernel/kexec_core.c      |  1 +
 kernel/power/hibernate.c |  2 ++
 kernel/reboot.c          | 16 ++++++++++++++++
 4 files changed, 20 insertions(+)

-- 
2.50.1

[PATCH v2 1/3] reboot: log the task that initiated the reboot

[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 userspace does not reliably record it
either: systemd only journals shutdowns that go through logind,
anything calling reboot(2) directly (watchdog daemons, container
agents, orchestration tooling) leaves no record at all, and the
journal is being torn down while the machine goes away, so even the
lines that should be written can be lost. The kernel is the only
place that always sees the caller, and a kernel log line survives
via pstore or a serial console when userspace logs do not.

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>
---
 include/linux/reboot.h |  1 +
 kernel/reboot.c        | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index aa08c3bbbf59..3fb8d8533563 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -172,6 +172,7 @@ extern void kernel_restart(char *cmd);
 extern void kernel_halt(void);
 extern void kernel_power_off(void);
 extern bool kernel_can_power_off(void);
+void reboot_log_initiator(void);
 
 void ctrl_alt_del(void);
 
diff --git a/kernel/reboot.c b/kernel/reboot.c
index bed6967bfa96..3f4534cd5b9c 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -717,6 +717,18 @@ EXPORT_SYMBOL_GPL(kernel_power_off);
 
 DEFINE_MUTEX(system_transition_mutex);
 
+/*
+ * Log the task that asked for the transition once the requested
+ * command is committed and can no longer fail, e.g:
+ *
+ *   reboot: initiated by systemd-shutdow[1]
+ *   reboot: Restarting system
+ */
+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
@@ -764,6 +776,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;
 
@@ -776,10 +789,12 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		break;
 
 	case LINUX_REBOOT_CMD_HALT:
+		reboot_log_initiator();
 		kernel_halt();
 		do_exit(0);
 
 	case LINUX_REBOOT_CMD_POWER_OFF:
+		reboot_log_initiator();
 		kernel_power_off();
 		do_exit(0);
 		break;
@@ -792,6 +807,7 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 		}
 		buffer[sizeof(buffer) - 1] = '\0';
 
+		reboot_log_initiator();
 		kernel_restart(buffer);
 		break;
 
-- 
2.50.1

[PATCH v2 2/3] kexec: log the task that initiated the kexec reboot

[Bradley Morgan]

The reboot syscall now logs the initiating task for the restart, halt
and power off commands at the point where they can no longer fail.
The kexec command could not be handled there: kernel_kexec() has
several failure points and returns to a running system when any of
them fires, which would leave a stale "initiated by" line in the log
with no transition behind it.

Call reboot_log_initiator() from kernel_kexec() once the shutdown
of the current kernel is committed, right before the existing
"Starting new kernel" line:

  reboot: initiated by kexec[713]
  kexec_core: Starting new kernel

The preserve_context path is left alone since it returns to the
running kernel instead of tearing it down.

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

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index dc770b9a6d05..23b7fe36e64e 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1200,6 +1200,7 @@ int kernel_kexec(void)
 		 * CPU hotplug again; so re-enable it here.
 		 */
 		cpu_hotplug_enable();
+		reboot_log_initiator();
 		pr_notice("Starting new kernel\n");
 		machine_shutdown();
 	}
-- 
2.50.1

[PATCH v2 3/3] PM: hibernate: log the task that initiated the power down

[Bradley Morgan]

Give the hibernation power down the same treatment as the reboot
syscall commands. hibernate() runs in the context of the task that
asked for it, whether through the reboot syscall or a write to
/sys/power/disk, so when power_down() runs current is still the
initiating task.

Log it once the image has been written and the machine is committed
to going down:

  reboot: initiated by systemd-sleep[812]
  reboot: Power down

The line comes from kernel/reboot.c so it keeps the "reboot:" prefix
and sits right next to the final "Restarting system", "Power down"
or "System halted" line, same as a plain reboot.

The one exception is platform mode rolling back on a pending wakeup
event after the line has been printed. The existing "Wakeup event
detected during hibernation, rolling back." line follows immediately
in that case, so the log stays real about what happened.

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

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index d2479c69d71a..bec91bf6a63c 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -687,6 +687,8 @@ static void power_down(void)
 	}
 #endif
 
+	reboot_log_initiator();
+
 	switch (hibernation_mode) {
 	case HIBERNATION_REBOOT:
 		kernel_restart(NULL);
-- 
2.50.1

Re: [PATCH v2 3/3] PM: hibernate: log the task that initiated the power down

[Rafael J. Wysocki (Intel)]

On Tue, Jul 21, 2026 at 5:14 PM Bradley Morgan <include@grrlz.net> wrote:
>
> Give the hibernation power down the same treatment as the reboot
> syscall commands.

Why?

> hibernate() runs in the context of the task that
> asked for it, whether through the reboot syscall or a write to

It doesn't use the reboot syscall.

> /sys/power/disk, so when power_down() runs current is still the
> initiating task.
>
> Log it once the image has been written and the machine is committed
> to going down:
>
>   reboot: initiated by systemd-sleep[812]
>   reboot: Power down
>
> The line comes from kernel/reboot.c so it keeps the "reboot:" prefix
> and sits right next to the final "Restarting system", "Power down"
> or "System halted" line, same as a plain reboot.
>
> The one exception is platform mode rolling back on a pending wakeup
> event after the line has been printed. The existing "Wakeup event
> detected during hibernation, rolling back." line follows immediately
> in that case, so the log stays real about what happened.

(a) Why is this information in the log useful?
(b) Do you realize that it only appears in the log when hibernation
fails or it may appear on a serial console or similar?

> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
>  kernel/power/hibernate.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index d2479c69d71a..bec91bf6a63c 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -687,6 +687,8 @@ static void power_down(void)
>         }
>  #endif
>
> +       reboot_log_initiator();
> +
>         switch (hibernation_mode) {
>         case HIBERNATION_REBOOT:
>                 kernel_restart(NULL);
> --

Re: [PATCH v2 3/3] PM: hibernate: log the task that initiated the power down

[Bradley Morgan]

On July 23, 2026 2:55:41 PM GMT+01:00, "Rafael J. Wysocki (Intel)"
<rafael@kernel.org> wrote:
>On Tue, Jul 21, 2026 at 5:14 PM Bradley Morgan <include@grrlz.net> wrote:
>>
>> Give the hibernation power down the same treatment as the reboot
>> syscall commands.
>
>Why?

1: Andrew suggested it [1]
2: because going down for hibernation is the same as "Wait, who the hell took the box down?!"


>
>> hibernate() runs in the context of the task that
>> asked for it, whether through the reboot syscall or a write to
>
>It doesn't use the reboot syscall.

Hmmm.... I may embarrass myself here, but it *could* (wink)

See kernel/reboot.c:

#ifdef CONFIG_HIBERNATION
	case LINUX_REBOOT_CMD_SW_SUSPEND:
		ret = hibernate();
		break;
#endif


>> /sys/power/disk,

I'm wrong: /sys/power/state

 so when power_down() runs current is still the
>> initiating task.
>>
>> Log it once the image has been written and the machine is committed
>> to going down:
>>
>>   reboot: initiated by systemd-sleep[812]
>>   reboot: Power down
>>
>> The line comes from kernel/reboot.c so it keeps the "reboot:" prefix
>> and sits right next to the final "Restarting system", "Power down"
>> or "System halted" line, same as a plain reboot.
>>
>> The one exception is platform mode rolling back on a pending wakeup
>> event after the line has been printed. The existing "Wakeup event
>> detected during hibernation, rolling back." line follows immediately
>> in that case, so the log stays real about what happened.
>
>(a) Why is this information in the log useful?

when the box just randomly goes down, some people prefer to know 
"And what process did this? Or what did this?", say

"Was it systemd-sleep? Or some random power daemon?? Or some stray
reboot(SW_SUSPEND)??"

Userspace logging can't really do this... 

There is software out there which can do this, but it's not the greatest.
[2]

Hence, this series!

>(b) Do you realize that it only appears in the log when hibernation
>fails or it may appear on a serial console or similar?

yeah. The image is written when the line prints, so after a successful
hibernate and resume dmesg won't have it.

Thats exactly the
same visibility as the final "Power down" / "Restarting system"  line it
sits next to

Well, if you want it, please say.


[1]:
https://lore.kernel.org/all/20260719231540.455bd5c3eac842686c05bd7f@linux-foundation.org/

[2]: https://docs.memfault.com/docs/linux/reboot-reason-tracking


(oh and btw, if you don't buy in, it's ok, just say.. any questions, ask)
:)

>
>> Signed-off-by: Bradley Morgan <include@grrlz.net>
>> ---
>>  kernel/power/hibernate.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
>> index d2479c69d71a..bec91bf6a63c 100644
>> --- a/kernel/power/hibernate.c
>> +++ b/kernel/power/hibernate.c
>> @@ -687,6 +687,8 @@ static void power_down(void)
>>         }
>>  #endif
>>
>> +       reboot_log_initiator();
>> +
>>         switch (hibernation_mode) {
>>         case HIBERNATION_REBOOT:
>>                 kernel_restart(NULL);
>> --
>

Thanks!

Re: [PATCH v2 3/3] PM: hibernate: log the task that initiated the power down

[Rafael J. Wysocki (Intel)]

On Thu, Jul 23, 2026 at 4:46 PM Bradley Morgan <include@grrlz.net> wrote:
>
> On July 23, 2026 2:55:41 PM GMT+01:00, "Rafael J. Wysocki (Intel)"
> <rafael@kernel.org> wrote:
> >On Tue, Jul 21, 2026 at 5:14 PM Bradley Morgan <include@grrlz.net> wrote:
> >>
> >> Give the hibernation power down the same treatment as the reboot
> >> syscall commands.
> >
> >Why?
>
> 1: Andrew suggested it [1]
> 2: because going down for hibernation is the same as "Wait, who the hell took the box down?!"

No, it is not the same unless the system doesn't resume.

> >
> >> hibernate() runs in the context of the task that
> >> asked for it, whether through the reboot syscall or a write to
> >
> >It doesn't use the reboot syscall.
>
> Hmmm.... I may embarrass myself here, but it *could* (wink)
>
> See kernel/reboot.c:
>
> #ifdef CONFIG_HIBERNATION
>         case LINUX_REBOOT_CMD_SW_SUSPEND:
>                 ret = hibernate();
>                 break;
> #endif

Ah, I'm wondering if anyone actually uses this, but fair enough.

> >> /sys/power/disk,
>
> I'm wrong: /sys/power/state
>
>  so when power_down() runs current is still the
> >> initiating task.
> >>
> >> Log it once the image has been written and the machine is committed
> >> to going down:
> >>
> >>   reboot: initiated by systemd-sleep[812]
> >>   reboot: Power down
> >>
> >> The line comes from kernel/reboot.c so it keeps the "reboot:" prefix
> >> and sits right next to the final "Restarting system", "Power down"
> >> or "System halted" line, same as a plain reboot.
> >>
> >> The one exception is platform mode rolling back on a pending wakeup
> >> event after the line has been printed. The existing "Wakeup event
> >> detected during hibernation, rolling back." line follows immediately
> >> in that case, so the log stays real about what happened.
> >
> >(a) Why is this information in the log useful?
>
> when the box just randomly goes down, some people prefer to know
> "And what process did this? Or what did this?", say
>
> "Was it systemd-sleep? Or some random power daemon?? Or some stray
> reboot(SW_SUSPEND)??"
>
> Userspace logging can't really do this...

But it doesn't really go down in the case of hibernation.  It's more
like suspend in that respect.

> There is software out there which can do this, but it's not the greatest.
> [2]
>
> Hence, this series!
>
> >(b) Do you realize that it only appears in the log when hibernation
> >fails or it may appear on a serial console or similar?
>
> yeah. The image is written when the line prints, so after a successful
> hibernate and resume dmesg won't have it.
>
> Thats exactly the
> same visibility as the final "Power down" / "Restarting system"  line it
> sits next to
>
> Well, if you want it, please say.
>
>
> [1]:
> https://lore.kernel.org/all/20260719231540.455bd5c3eac842686c05bd7f@linux-foundation.org/
>
> [2]: https://docs.memfault.com/docs/linux/reboot-reason-tracking
>
>
> (oh and btw, if you don't buy in, it's ok, just say.. any questions, ask)
> :)

Yeah, I'm not convinced.

Re: [PATCH v2 3/3] PM: hibernate: log the task that initiated the power down

[Bradley Morgan]

On July 23, 2026 3:55:10 PM GMT+01:00, "Rafael J. Wysocki (Intel)"
<rafael@kernel.org> wrote:
>On Thu, Jul 23, 2026 at 4:46 PM Bradley Morgan <include@grrlz.net> wrote:
>>
>> On July 23, 2026 2:55:41 PM GMT+01:00, "Rafael J. Wysocki (Intel)"
>> <rafael@kernel.org> wrote:
>> >On Tue, Jul 21, 2026 at 5:14 PM Bradley Morgan <include@grrlz.net>
>wrote:
>> >>
>> >> Give the hibernation power down the same treatment as the reboot
>> >> syscall commands.
>> >
>> >Why?
>>
>> 1: Andrew suggested it [1]
>> 2: because going down for hibernation is the same as "Wait, who the hell
>took the box down?!"
>
>No, it is not the same unless the system doesn't resume.
>
>> >
>> >> hibernate() runs in the context of the task that
>> >> asked for it, whether through the reboot syscall or a write to
>> >
>> >It doesn't use the reboot syscall.
>>
>> Hmmm.... I may embarrass myself here, but it *could* (wink)
>>
>> See kernel/reboot.c:
>>
>> #ifdef CONFIG_HIBERNATION
>>         case LINUX_REBOOT_CMD_SW_SUSPEND:
>>                 ret = hibernate();
>>                 break;
>> #endif
>
>Ah, I'm wondering if anyone actually uses this, but fair enough.
>
>> >> /sys/power/disk,
>>
>> I'm wrong: /sys/power/state
>>
>>  so when power_down() runs current is still the
>> >> initiating task.
>> >>
>> >> Log it once the image has been written and the machine is committed
>> >> to going down:
>> >>
>> >>   reboot: initiated by systemd-sleep[812]
>> >>   reboot: Power down
>> >>
>> >> The line comes from kernel/reboot.c so it keeps the "reboot:" prefix
>> >> and sits right next to the final "Restarting system", "Power down"
>> >> or "System halted" line, same as a plain reboot.
>> >>
>> >> The one exception is platform mode rolling back on a pending wakeup
>> >> event after the line has been printed. The existing "Wakeup event
>> >> detected during hibernation, rolling back." line follows immediately
>> >> in that case, so the log stays real about what happened.
>> >
>> >(a) Why is this information in the log useful?
>>
>> when the box just randomly goes down, some people prefer to know
>> "And what process did this? Or what did this?", say
>>
>> "Was it systemd-sleep? Or some random power daemon?? Or some stray
>> reboot(SW_SUSPEND)??"
>>
>> Userspace logging can't really do this...
>
>But it doesn't really go down in the case of hibernation.  It's more
>like suspend in that respect.
>
>> There is software out there which can do this, but it's not the
>greatest.
>> [2]
>>
>> Hence, this series!
>>
>> >(b) Do you realize that it only appears in the log when hibernation
>> >fails or it may appear on a serial console or similar?
>>
>> yeah. The image is written when the line prints, so after a successful
>> hibernate and resume dmesg won't have it.
>>
>> Thats exactly the
>> same visibility as the final "Power down" / "Restarting system"  line it
>> sits next to
>>
>> Well, if you want it, please say.
>>
>>
>> [1]:
>>
>https://lore.kernel.org/all/20260719231540.455bd5c3eac842686c05bd7f@linux-foundation.org/
>>
>> [2]: https://docs.memfault.com/docs/linux/reboot-reason-tracking
>>
>>
>> (oh and btw, if you don't buy in, it's ok, just say.. any questions,
>ask)
>> :)
>
>Yeah, I'm not convinced.
>


ack, dropped.

btw. I wasn't the surest anyway abt swusp, don't worry.

thanks for the review and sorry for wasting your time

Thanks!