SYSTEMD-KEXEC.SERVICE(8)

💖 NAME 💖

systemd-poweroff.service, systemd-halt.service, systemd-reboot.service, systemd-kexec.service, systemd-shutdown — the whole shutdown logic situation, bestie. Yes this is the systemd-poweroff.service(8) page and yes it brought its friends.

---

✨ SYNOPSIS ✨

systemd-poweroff.service

systemd-halt.service

systemd-reboot.service

systemd-kexec.service

/usr/lib/systemd/systemd-shutdown

/usr/lib/systemd/system-shutdown/

🦋 DESCRIPTION 🦋

okay so picture this: systemd-poweroff.service is a system service that gets pulled in by poweroff.target, and it's literally the one in charge of the actual system power-off operation. iconic. and the same energy runs through the whole squad — systemd-halt.service gets pulled in by halt.target, systemd-reboot.service by reboot.target, and systemd-kexec.service by kexec.target, each one executing its respective action. matching set, no notes. 💅

when these services run, they make sure PID 1 gets replaced by the /usr/lib/systemd/systemd-shutdown binary, and that binary is the one actually responsible for the actual shutdown. before shutting down, it's gonna try to unmount all the remaining file systems (or at least remount them read-only), disable all the remaining swap devices, detach all the remaining storage devices, and kill all the remaining processes. it's giving spring cleaning but make it fatal. 🧹

and why does this code have to live in a separate binary?? the tea is: otherwise rebooting after an upgrade might be broken — the running PID 1 could still depend on libraries which are not available any more, thus keeping the file system busy, which then cannot be re-mounted read-only. so it's not extra, it's necessary, periodt.

shortly before executing the actual system power-off/halt/reboot/kexec, systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/. those executables get called with one argument: either "poweroff", "halt", "reboot", or "kexec", depending on the chosen action.

all executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished. (a safety timeout of 90s is applied however — so nobody's waiting forever, slay.) but lowkey important: note that these executables are run after all services have been shut down, and after most mounts have been unmounted (the root file system as well as /run/ and various API file systems are still around though). which means any programs you drop into this directory must be prepared to run in such a limited execution environment and not rely on external services or hierarchies such as /var/ to be around (or writable). tiny little apocalypse vibes, plan accordingly. 💀

also pls pls pls: note that systemd-poweroff.service (and the related units) should never be executed directly. instead, trigger system shutdown with a command such as systemctl poweroff. do not run the unit by hand, that's not the move, that's the opposite of the move.

one more thing, another form of shutdown is provided by the systemd-soft-reboot.service(8) functionality. it reboots only the OS userspace, leaving the kernel, firmware, and hardware as it is. soft launch energy. 🌸

---

🌈 SEE ALSO 🌈

• systemd(1)
• systemctl(1)
• systemd.special(7)
• reboot(2)
• systemd-suspend.service(8)
• systemd-soft-reboot.service(8)
• bootup(7)

---

and that's the whole page, bestie 🫶 — this was systemd 262.1, the systemd-poweroff.service(8) manual, and you absolutely ate reading it. go shut something down the correct way. 💖✨