[systemd-devel] systemctl reboot get terminated by signal 15

[Pengpeng Sun]

Thanks Lennart!
I reproduced the issue after set "systemd-analyze log-level debug". It turns out 'systemctl reboot' triggered before all the steps logged in 'journalctl -a'. But I did get the stderr of 'systemctl reboot', paste it as below, please check if it helps to locate the root cause.
And besides 'journalctl -a', where can I get the systemd debug logs?

stderr: Bus n/a: changing state UNSET → OPENING
Bus n/a: changing state OPENING → AUTHENTICATING
Executing dbus call org.freedesktop.systemd1.Manager StartUnit(reboot.target, replace-irreversibly)
Bus n/a: changing state AUTHENTICATING → RUNNING
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=5 reply_cookie=1 signature=o error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=GetUnit cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a

--
Best regards,
Pengpeng 

On 2021/4/19, 10:37 PM, "Lennart Poettering" <lennart at poettering.net> wrote:

    On Mo, 19.04.21 14:29, Pengpeng Sun (pengpengs at vmware.com) wrote:

    > Hi there,
    >
    > Our program executes 'systemctl reboot' in a child process to reboot
    > Linux right after its booted, Sometimes there is no error, but
    > sometimes the child process terminated due to received uncaught
    > signal 15, then no reboot happened. WIFSIGNALED evaluated a non-zero
    > value, WTERMSIG evaluated 15. Don't understand why the uncaught
    > signal 15 happened here, could you please shed light on this,
    > Thanks.

    15 is SIGTERM, i.e. the signal sent when a process is politely asked
    to shut down. Something is terminating your process.

    It could be systemd, could be something else.

    To track down what it is, maybe turn on debug logging in systemd, maybe
    you find the explanation there. i.e. "systemd-analyze log-level debug"
    and then reproduce the issue.

    ALternatively, install a signal handler for SIGTERM via sigaction, and
    look into the .si_pid field of the siginfo_t you can receive in the
    handler. It tells you which processes sent the SIGTERM.

    Lennart

    --
    Lennart Poettering, Berlin