[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
> example with LINUX_REBOOT_CMD_POWER_OFF ?
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
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list