On Sun, Apr 12, 2015 at 6:46 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Fri, 10.04.15 12:35, Ani Sinha (a...@arista.com) wrote: > >> On Fri, Apr 10, 2015 at 10:18 AM, Ani Sinha <a...@arista.com> wrote: >> > Thanks Lennart for the clarification. Much appreciated! >> > >> > Ani >> > >> > >> > On Fri, Apr 10, 2015 at 8:58 AM, Lennart Poettering >> > <lenn...@poettering.net> wrote: >> >> On Fri, 10.04.15 08:40, Ani Sinha (a...@arista.com) wrote: >> >> >> >>> On Fri, Apr 10, 2015 at 1:13 AM, Daniel Mack <dan...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel