[systemd-devel] proper way to shutdown/reboot host with systemd

Lennart Poettering lennart at poettering.net
Tue Aug 26 12:33:43 PDT 2014

On Tue, 26.08.14 22:54, Vasiliy Tolstov (v.tolstov at selfip.ru) wrote:

> 2014-08-26 21:32 GMT+04:00 Lennart Poettering <lennart at poettering.net>:
> > From which language? From C, I'd recommend issuing the PowerOff() method
> > on logind's manager object via the bus. From the shell, i'd recommend
> > "systemctl poweroff", which does exactly that.
> Thanks, but does it possible to shutdown system via reboot syscall for

Hmm? What's "possible" supposed to mean? I mean, certainly you can
invoke that syscall, and "systemctl reboot -ff" will do that for
you. But I'd really recommend not ever doing that, unless your system is
seriously stuck.

In systemd, there are three ways to shut down the system:

1) The recommended way, by invoking PowerOff() on logind's manager
   object. This will do polkit, respects inhibitors and
   everything. Internally this then enqueues a start job for the
   "poweroff.target"  unit in PID 1, which the shuts down the system
   cleanly, and terminates all services in order. THis is accessible via
   "systemctl poweroff".

2) The more agressive way, by invokign PowerOff() on PID1's
   manager interface. This tells systemd to immediately go in the final
   killing spree, without bothering with polkit, inhibitors or correctly
   terminating all services in the right order. This is not nice to
   system services and user applications, but will still unmount all the
   file systems, detach loopback/DM/... and so on. This is accessible
   via "systemctl poweroff -f". Also by sending SIGRTMIN+14 to PID 1.

3) The super-agressive way, by invoking the reboot() syscall
   directly. This doesn't bother with unmounting, or anything else, it
   just resets the machine. THis is accessible via "systemctl poweroff
   -ff" (which however, does a sync() before, but nothing else, the
   filesystem will be marked dirty on next reboot, you will get fsck
   started, still).

Usually there's no reason to ever use anything but #1.


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list