Re: systemctl reboot get terminated by signal 15

[Pengpeng Sun <pengpengs@xxxxxxxxxx>]

Hi Lennart,

After installed a signal handler for SIGTERM and reproduced the issue, got si_pid is 1 which is systemd.

Also paste the stderr here:
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
Got message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=131 reply_cookie=2 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/unit/reboot_2etarget interface=org.freedesktop.DBus.Properties member=Get cookie=3 reply_cookie=0 signature=ss error-name=n/a error-message=n/a

What make systemd triggered SIGTERM when calling 'systemd reboot'? 

--
Best regards,
Pengpeng 

On 2021/4/21, 12:48 AM, "Pengpeng Sun" <pengpengs@xxxxxxxxxx> wrote:

    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@xxxxxxxxxxxxxx> wrote:

        On Mo, 19.04.21 14:29, Pengpeng Sun (pengpengs@xxxxxxxxxx) 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


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel