[systemd-devel] issuing 'reboot' command does not print the familiar 'Restarting system.' message

[Ani Sinha]

On Sun, Apr 12, 2015 at 6:46 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 10.04.15 12:35, Ani Sinha (ani at arista.com) wrote:
>
>> On Fri, Apr 10, 2015 at 10:18 AM, Ani Sinha <ani at arista.com> wrote:
>> > Thanks Lennart for the clarification. Much appreciated!
>> >
>> > Ani
>> >
>> >
>> > On Fri, Apr 10, 2015 at 8:58 AM, Lennart Poettering
>> > <lennart at poettering.net> wrote:
>> >> On Fri, 10.04.15 08:40, Ani Sinha (ani at arista.com) wrote:
>> >>
>> >>> On Fri, Apr 10, 2015 at 1:13 AM, Daniel Mack <daniel at zonque.org> wrote:
>> >>> > On 04/10/2015 04:18 AM, Ani Sinha wrote:
>> >>> >> OK I have one more question. Does every call path in the reboot
>> >>> >> command use the Linux reboot() sys call? I'm not familiar with dbus
>> >>> >> stuff but looking at the code seems to indicate that there might be
>> >>> >> some paths where reboot() is not issued. Just wanted to run by you
>> >>> >> guys since you guys know the code best.
>> >>> >
>> >>> > The reboot command is symlinked to systemctl, which is a multi-call
>> >>> > binary. When invoked as 'reboot', 'shutdown', 'halt', 'poweroff' etc, it
>> >>> > communicates with PID1 and tells it to start one of the shutdown
>> >>> > targets. This way, the system will shut down and stop services in a
>> >>> > clean way. Once the target is reached, the reboot() syscall is issued to
>> >>> > the kernel.
>> >>>
>> >>> Can you please point me to the code and function call that processes
>> >>> the 'reboot' target from PID 1?
>> >>
>> >> reboot.target pulls in systemd-reboot.service, which wraps
>> >> "/usr/bin/systemctl --force reboot", which issues the Reboot() call on
>> >> PID1's bus API, which causes it to execute /usr/lib/systemd-shutdown
>> >> as PID 1 which then kills everything and reboots.
>>
>> OK I see it now. shutdownd.c eventually issues 'shutdown -r now'. This
>> gets parsed by shutdown_parse_argv(). Eventually we end up calling
>> halt_main() ->halt_now() ->reboot(RB_AUTOBOOT).
>
> Hmm?
>
> shutdownd's only raison d'etre is to support scheduled shutdowns. It's
> not used unless you actually use scheduled shutdowns.

Yes you are right. I looked at shutdownd and later on also looked at
the core/shutdown.c, later being a more direct path to reboot() call.

If you just use
> "systemctl poweroff" or so, then it will *not* be used at all, and is
> not involved at all in the shutdown logic.

again, sorry for the confusion.

>
> And no! shutdownd will never call halt_main(), nor halt_now(), nor
> reboot(RB_AUTOBOUT). If you use shutdownd, then this will result in
> the equiavlent of "systemctl poweroff" and so on, just delayed a bit.

yes, it does not go through that code path directly. I was referring
to this piece of code where it execs "shutdown" :

execl(SYSTEMCTL_BINARY_PATH,
   "shutdown",
    sw,
    "now",
     (b.command.warn_wall && b.command.wall_message[0]) ?
b.command.wall_message :
     (b.command.warn_wall ? NULL : "--no-wall"),
                      NULL);

I should have been clearer in my earlier comment.

>
> Please don't confuse shutdownd.c and shutdown.c. The former is just
> there for the scheduled shutdown bits, the latter is the always used
> last part of the shutdown logic.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat