systemctl/journal: log pid/unit of the process initiating system action #28579

kmlyn · 2023-07-29T17:10:21Z

This PR implements logging the initiator (and entire task chain up to PID 1) to authpriv facility, satisfying RFE from issue #27847.

Please find below an example of what is logged:

Jul 29 18:29:39 fedora shutdown[849]: System action power off was requested, task chain is printed below:
Jul 29 18:29:39 fedora shutdown[849]:        PID        UID CMDLINE
Jul 29 18:29:39 fedora shutdown[849]:        807          0 -bash
Jul 29 18:29:39 fedora shutdown[849]:        784          0 login -- root
Jul 29 18:29:39 fedora shutdown[849]:          1          0 /usr/lib/systemd/systemd --switched-root --system --deserialize…(+)

If you have an idea how to improve this solution, your ideas are welcome.

…on (poweroff, reboot, etc.) to authpriv facility

…on (poweroff, reboot, etc.) to authpriv facility – fixed memory leak reported during tests

keszybz · 2023-07-31T09:25:15Z

Please move the issue number to message body: Fixes #28579..

Also squash the two commits.

keszybz

I started reviewing the code, so I made some comments about implementation details. But we should probably talk about the high-level picture first. Why do you want to log the full chain? Wouldn't it be enough to log one line about the process which requested the shutdown, and the service name of that process?

src/basic/log.c

keszybz · 2023-07-31T09:37:58Z

Oh, you're logging this from systemctl. I'm pretty sure that any logging should happen from PID1, so that all calls over dbus are covered.

src/basic/log.c

kmlyn · 2023-07-31T22:10:51Z

I started reviewing the code, so I made some comments about implementation details. But we should probably talk about the high-level picture first. Why do you want to log the full chain? Wouldn't it be enough to log one line about the process which requested the shutdown, and the service name of that process?

I believe logging a full task chain would be beneficial for better understanding of the ancestry of the process requesting system action. If such process runs as a part of a service, adding this information to the log would indeed make sense.

bluca · 2023-08-01T09:08:00Z

I started reviewing the code, so I made some comments about implementation details. But we should probably talk about the high-level picture first. Why do you want to log the full chain? Wouldn't it be enough to log one line about the process which requested the shutdown, and the service name of that process?

I believe logging a full task chain would be beneficial for better understanding of the ancestry of the process requesting system action. If such process runs as a part of a service, adding this information to the log would indeed make sense.

We already know who calls what at the receiver, because it comes via D-Bus. I'm pretty sure all of this is already logged at debug level, so instead just log it at the receiver's end. Look at the daemon-reload/daemon-reexec commands, those already log the caller, you can do the same thing.

kmlyn · 2023-08-15T00:07:05Z

We already know who calls what at the receiver, because it comes via D-Bus. I'm pretty sure all of this is already logged at debug level, so instead just log it at the receiver's end. Look at the daemon-reload/daemon-reexec commands, those already log the caller, you can do the same thing.

In the solution presented so far, I was not even considering messaging anything via D-Bus – I went the simplest (and wrong) road of using log_* functions from systemctl directly. Your hint is fantastic and I will revamp the patch.

bluca · 2023-08-15T00:34:45Z

check out how it's done for daemon-reload:

systemd/src/core/dbus-manager.c

Line 1598 in 672de61

    
           static void log_caller(sd_bus_message *message, Manager *manager, const char *method) {

kmlyn · 2023-08-15T06:49:42Z

I did check that yesterday and found that function. Today I'll work on it further.

…ng performed by daemons to authpriv.

src/shared/log-task-chain.c

kmlyn · 2023-09-16T13:42:31Z

Now, we have:

Sep 16 15:12:12 fedora systemd[1]: Action 'reload' requested from client PID 620 ('systemctl') (unit session-2.scope).
/snip/
Sep 16 15:12:16 fedora systemd[1]: Action 'reexecute' requested from client PID 653 ('systemctl') (unit session-2.scope).
/snip/
Sep 16 15:13:00 fedora systemd[1]: Received SIGINT from PID 573 (bash) (unit session-2.scope).
/snip/
Sep 16 15:15:43 fedora systemd[1]: Action 'reboot' requested from client PID 609 ('systemctl') (unit session-2.scope).
/snip/
Sep 16 15:16:51 fedora systemd-logind[509]: Action 'reboot' requested from client PID 598 ('systemctl') (unit session-2.scope).
/snip/
Sep 16 15:18:00 fedora systemd-logind[508]: Action 'reboot' requested from client PID 596 ('reboot') (unit session-2.scope).
/snip/
Sep 16 15:26:42 fedora systemd-logind[512]: Action 'poweroff' requested from client PID 635 ('poweroff') (unit session-2.scope).

Unfortunately, it's still possible to run, for instance, systemctl start reboot.target and the caller is not logged which is expected given where the logging is currently plugged. As of now, I don't see an elegant solution to this, so I'm open to guidance.

When exiting PID 1 we most likely don't have stdio/stdout open, so the final LSan check would not print any actionable information and would just crash PID 1 leading up to a kernel panic, which is a bit annoying. Let's instead attempt to open /dev/console, and if we succeed redirect LSan's report there. The result is a bit messy, as it's slightly interleaved with the kernel panic, but it's definitely better than not having the stack trace at all: [ OK ] Reached target final.target. [ OK ] Finished systemd-poweroff.service. [ OK ] Reached target poweroff.target. ================================================================= 3 1m 43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1 ==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 [ 43.254683] Call Trace: [ 43.254911] <TASK> [ 43.255107] dump_stack_lvl+0x47/0x60 S[ a 43.n2555i05] panic+t0x192/0x350 izer[ :43.255966 ] do_exit+0x990/0xdb10 etec[ 43.256504] do_group_exit+0x31/0x80 [ 43.256889] __x64_sys_exit_group+0x18/0x20 [ 43.257288] do_syscall_64+0x60/0x90 o_user_mod leaks[ 43.257618] ? syscall_exit_t +0x2b/0x40 [ 43.258411] ? do_syscall_64+0x6c/0x90 1mDirect le[ 43.258755] ak of 21 byte(s)? exc_page_fault+0x7f/0x180 [ 43.259446] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 43.259901] RiIP: 0033:0x7f357nb8f3ad4 1 objec[ 43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051 [ 43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd [ 43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001 [ 43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef [ 43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000 [ 43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007 [ 43.267517] </TASK> #0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f) #1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132 #2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190 #3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234 #4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734 #5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621 #6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406 #7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319 #8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439 #9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007 #10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049 #11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269 #12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296 #13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638 #14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187 #15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808 #16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869 #17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244 #18 0x41db21 in invoke_main_loop ../src/core/main.c:1960 #19 0x426615 in main ../src/core/main.c:3125 #20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). [ 43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]--- Originally noticed in systemd#28579.

When exiting PID 1 we most likely don't have stdio/stdout open, so the final LSan check would not print any actionable information and would just crash PID 1 leading up to a kernel panic, which is a bit annoying. Let's instead attempt to open /dev/console, and if we succeed redirect LSan's report there. The result is a bit messy, as it's slightly interleaved with the kernel panic, but it's definitely better than not having the stack trace at all: [ OK ] Reached target final.target. [ OK ] Finished systemd-poweroff.service. [ OK ] Reached target poweroff.target. ================================================================= 3 1m 43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1 ==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 [ 43.254683] Call Trace: [ 43.254911] <TASK> [ 43.255107] dump_stack_lvl+0x47/0x60 S[ a 43.n2555i05] panic+t0x192/0x350 izer[ :43.255966 ] do_exit+0x990/0xdb10 etec[ 43.256504] do_group_exit+0x31/0x80 [ 43.256889] __x64_sys_exit_group+0x18/0x20 [ 43.257288] do_syscall_64+0x60/0x90 o_user_mod leaks[ 43.257618] ? syscall_exit_t +0x2b/0x40 [ 43.258411] ? do_syscall_64+0x6c/0x90 1mDirect le[ 43.258755] ak of 21 byte(s)? exc_page_fault+0x7f/0x180 [ 43.259446] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 43.259901] RiIP: 0033:0x7f357nb8f3ad4 1 objec[ 43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051 [ 43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd [ 43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001 [ 43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef [ 43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000 [ 43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007 [ 43.267517] </TASK> #0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f) #1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132 #2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190 #3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234 #4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734 #5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621 #6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406 #7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319 #8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439 #9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007 #10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049 #11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269 #12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296 #13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638 #14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187 #15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808 #16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869 #17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244 #18 0x41db21 in invoke_main_loop ../src/core/main.c:1960 #19 0x426615 in main ../src/core/main.c:3125 #20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). [ 43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]--- Originally noticed in #28579.

bluca · 2023-09-17T11:40:00Z

src/login/logind-dbus.c


        (void) setup_wall_message_timer(m, message);

+        if (IN_SET(a->handle, HANDLE_HALT, HANDLE_REBOOT, HANDLE_POWEROFF, HANDLE_KEXEC, 


HANDLE_SOFT_REBOOT is missing

Hmm, is this check really necessary? The function shouldn't have been called if we're not doing shutdown or sleep operation. Maybe add an assertion instead?

please use th ehelpers in #29377.

But yeah, an assert should be more appropriate here

bluca · 2023-09-17T11:43:04Z

src/core/dbus-manager.c

                return sd_bus_error_setf(error, SD_BUS_ERROR_NOT_SUPPORTED,
                                         "Powering off is only supported for system managers.");

+        bus_log_caller(message, "poweroff");


also add a call in the method_soft_reboot() function above

bluca

please rebase and squash all commits into the first one when pushing

YHNdnzj · 2023-09-17T11:46:19Z

src/basic/log.c

+                         "Received SIG%s from PID %"PRIu32" (%s)%s%s%s.",
                         signal_to_string(si->ssi_signo),
-                         si->ssi_pid, strna(p));
+                         si->ssi_pid, strna(p), u ? " (unit " : "", u ? u : "", u ? ")" : "");


Suggested change

si->ssi_pid, strna(p), u ? " (unit " : "", u ? u : "", u ? ")" : "");

si->ssi_pid, strna(p),

u ? " (unit " : "", strempty(u), u ? ")" : "");

YHNdnzj · 2023-09-17T11:56:24Z

src/login/logind-dbus.c


        (void) setup_wall_message_timer(m, message);

+        if (IN_SET(a->handle, HANDLE_HALT, HANDLE_REBOOT, HANDLE_POWEROFF, HANDLE_KEXEC, 


Hmm, is this check really necessary? The function shouldn't have been called if we're not doing shutdown or sleep operation. Maybe add an assertion instead?

YHNdnzj · 2023-09-17T11:58:49Z

src/shared/bus-util.c

+        log_info("Action '%s' requested from client PID " PID_FMT "%s%s%s%s%s%s.",
+                 method, pid,
+                 comm ? " ('" : "", strempty(comm), comm ? "')" : "",
+                 caller ? " (unit " : "", caller ? caller : "", caller ? ")" : "");


strempty here too

YHNdnzj · 2023-09-17T12:01:40Z

src/shared/bus-util.c

+        caller = unit_creds;
+
+        if (!unit_creds) {
+                cg_pid_get_unit(pid, &unit_pid);
+                caller = unit_pid;
+        }


I'd like the two cases to be merged, i.e. we only assign caller once.

YHNdnzj · 2023-09-17T12:03:13Z

src/shared/bus-util.c

+
+void bus_log_caller(sd_bus_message *message, const char *method) {
+        _cleanup_(sd_bus_creds_unrefp) sd_bus_creds *creds = NULL;
+        _cleanup_free_ char *unit_pid = NULL;


Purely bikeshedding, but I'd like to name this unit_from_pid.

poettering · 2023-09-29T20:04:48Z

could you please squash your commits. We want "perfect PRs", i.e. every commit in the PR should make sense on its own, but not necessarily reflect development history. It's just bad to review, and sucks for bisectability if PRs aren't clean in that regard.

poettering · 2023-09-29T20:06:53Z

src/shared/bus-util.c

+        caller = unit_creds;
+
+        if (!unit_creds) {
+                cg_pid_get_unit(pid, &unit_pid);


SD_BUS_CREDS_AUGMENT|SD_BUS_CREDS_UNIT (which you specify above) does exactly this already. Please drop this redundant step hence.

It added that because unit extraction from credentials after daemon-reload and daemon-reexec actions failed though I don't understand why.

I will check again after rebasing this branch on top of main.

…helpers Let's group this HandleAction types in nice little helpers. Prompted by systemd#28579

…helpers Let's group this HandleAction types in nice little helpers. Prompted by #28579

kmlyn · 2023-10-02T22:05:41Z

Thank you for all reviews and pointers. I've been busy after work recently but I'll finally have some time during the nearest weekend to perform all tasks (i.e., adding requested changes, squashing all commits, rebasing on top of main).

When exiting PID 1 we most likely don't have stdio/stdout open, so the final LSan check would not print any actionable information and would just crash PID 1 leading up to a kernel panic, which is a bit annoying. Let's instead attempt to open /dev/console, and if we succeed redirect LSan's report there. The result is a bit messy, as it's slightly interleaved with the kernel panic, but it's definitely better than not having the stack trace at all: [ OK ] Reached target final.target. [ OK ] Finished systemd-poweroff.service. [ OK ] Reached target poweroff.target. ================================================================= 3 1m 43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1 ==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 [ 43.254683] Call Trace: [ 43.254911] <TASK> [ 43.255107] dump_stack_lvl+0x47/0x60 S[ a 43.n2555i05] panic+t0x192/0x350 izer[ :43.255966 ] do_exit+0x990/0xdb10 etec[ 43.256504] do_group_exit+0x31/0x80 [ 43.256889] __x64_sys_exit_group+0x18/0x20 [ 43.257288] do_syscall_64+0x60/0x90 o_user_mod leaks[ 43.257618] ? syscall_exit_t +0x2b/0x40 [ 43.258411] ? do_syscall_64+0x6c/0x90 1mDirect le[ 43.258755] ak of 21 byte(s)? exc_page_fault+0x7f/0x180 [ 43.259446] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 43.259901] RiIP: 0033:0x7f357nb8f3ad4 1 objec[ 43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051 [ 43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd [ 43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001 [ 43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef [ 43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000 [ 43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007 [ 43.267517] </TASK> #0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f) #1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132 #2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190 #3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234 #4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734 #5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621 #6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406 #7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319 #8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439 #9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007 #10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049 #11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269 #12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296 #13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638 #14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187 #15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808 #16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869 #17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244 #18 0x41db21 in invoke_main_loop ../src/core/main.c:1960 #19 0x426615 in main ../src/core/main.c:3125 #20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). [ 43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]--- Originally noticed in systemd/systemd#28579.

journal: add logging task chain of the process initiating system acti…

3f958ce

…on (poweroff, reboot, etc.) to authpriv facility

github-actions bot added systemctl util-lib please-review PR is ready for (re-)review by a maintainer labels Jul 29, 2023

journal: add logging task chain of the process initiating system acti…

dfb668d

…on (poweroff, reboot, etc.) to authpriv facility – fixed memory leak reported during tests

kmlyn changed the title ~~journal: add logging task chain of the process initiating system action – RFE #27847~~ systemctl/journal: add logging task chain of the process initiating system action – RFE #27847 Jul 30, 2023

keszybz added the squash-on-merge label Jul 31, 2023

keszybz reviewed Jul 31, 2023

View reviewed changes

src/basic/log.c Outdated Show resolved Hide resolved

src/basic/log.c Outdated Show resolved Hide resolved

src/basic/log.c Outdated Show resolved Hide resolved

keszybz added needs-discussion 🤔 and removed please-review PR is ready for (re-)review by a maintainer labels Jul 31, 2023

YHNdnzj requested changes Jul 31, 2023

View reviewed changes

src/basic/log.c Outdated Show resolved Hide resolved

src/basic/log.c Outdated Show resolved Hide resolved

kmlyn changed the title ~~systemctl/journal: add logging task chain of the process initiating system action – RFE #27847~~ systemctl/journal: add logging task chain of the process initiating system action – Fixes #27847 Jul 31, 2023

bluca added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Aug 1, 2023

Feature reworked: log_task_chain() moved to shared library, all loggi…

25174d5

…ng performed by daemons to authpriv.

github-actions bot added build-system meson please-review PR is ready for (re-)review by a maintainer and removed reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks labels Aug 27, 2023

bluca reviewed Aug 27, 2023

View reviewed changes

src/shared/log-task-chain.c Outdated Show resolved Hide resolved

bluca reviewed Aug 27, 2023

View reviewed changes

src/shared/log-task-chain.c Outdated Show resolved Hide resolved

bluca added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks and removed please-review PR is ready for (re-)review by a maintainer labels Aug 27, 2023

This comment was marked as spam.

Sign in to view

github-actions bot removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Sep 16, 2023

mrc0mmand mentioned this pull request Sep 16, 2023

core: redirect LSan's report to /dev/console during manager exit #29194

Merged

Fixing possible source of leak reported by ci/cd with sanitizers

47e10ae

bluca reviewed Sep 17, 2023

View reviewed changes

bluca approved these changes Sep 17, 2023

View reviewed changes

bluca added good-to-merge/with-minor-suggestions and removed needs-discussion 🤔 build-system meson please-review PR is ready for (re-)review by a maintainer labels Sep 17, 2023

bluca changed the title ~~systemctl/journal: add logging task chain of the process initiating system action – Fixes #27847~~ systemctl/journal: log pid/unit of the process initiating system action Sep 17, 2023

bluca linked an issue Sep 17, 2023 that may be closed by this pull request

Logging what or who initiated suspend/reboot/shutdown #27847

Open

YHNdnzj reviewed Sep 17, 2023

View reviewed changes

poettering reviewed Sep 29, 2023

View reviewed changes

poettering added a commit to poettering/systemd that referenced this pull request Sep 29, 2023

logind: add HANDLE_ACTION_IS_SLEEP() and HANDLE_ACTION_IS_SHUTDOWN() …

9d223f2

…helpers Let's group this HandleAction types in nice little helpers. Prompted by systemd#28579

poettering mentioned this pull request Sep 29, 2023

logind: add HANDLE_ACTION_IS_SLEEP() and HANDLE_ACTION_IS_SHUTDOWN() … #29377

Merged

poettering added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks and removed good-to-merge/with-minor-suggestions labels Sep 29, 2023

bluca pushed a commit that referenced this pull request Sep 30, 2023

logind: add HANDLE_ACTION_IS_SLEEP() and HANDLE_ACTION_IS_SHUTDOWN() …

cb88da8

…helpers Let's group this HandleAction types in nice little helpers. Prompted by #28579

kmlyn closed this Sep 7, 2025

github-actions bot removed reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks squash-on-merge labels Sep 7, 2025


		(void) setup_wall_message_timer(m, message);

		if (IN_SET(a->handle, HANDLE_HALT, HANDLE_REBOOT, HANDLE_POWEROFF, HANDLE_KEXEC,

	si->ssi_pid, strna(p), u ? " (unit " : "", u ? u : "", u ? ")" : "");
	si->ssi_pid, strna(p),
	u ? " (unit " : "", strempty(u), u ? ")" : "");

Uh oh!

systemctl/journal: log pid/unit of the process initiating system action #28579

systemctl/journal: log pid/unit of the process initiating system action #28579

Uh oh!

Conversation

kmlyn commented Jul 29, 2023

Uh oh!

keszybz commented Jul 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

keszybz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

keszybz commented Jul 31, 2023

Uh oh!

Uh oh!

Uh oh!

kmlyn commented Jul 31, 2023

Uh oh!

bluca commented Aug 1, 2023

Uh oh!

kmlyn commented Aug 15, 2023

Uh oh!

bluca commented Aug 15, 2023

Uh oh!

kmlyn commented Aug 15, 2023

Uh oh!

Uh oh!

Uh oh!

This comment was marked as spam.

Uh oh!

kmlyn commented Sep 16, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bluca left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

poettering commented Sep 29, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kmlyn commented Oct 2, 2023

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

6 participants

keszybz commented Jul 31, 2023 •

edited

Loading