[systemd-devel] Scheduling unit at reboot.target and shutdown.target
Lennart Poettering
lennart at poettering.net
Fri Oct 27 10:25:56 UTC 2017
On Fr, 27.10.17 11:43, D.S. Ljungmark (spider at aanstoot.se) wrote:
> So, I've got a piece of hardware I want to do a final handover to just
> around reboot.target / shutdown.target
>
> This will then cause the entire CPU and hardware allocated to it to
> actually drop power (and schedule re-power), so I don't want to do this
> earlier.
>
>
>
> Is it simply to do:
>
> [Unit]
> DefaultDependencies=no
>
> [Service]
> ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
> Type=oneshot
>
> [Install]
> WantedBy=reboot.target
>
> or am I missing something here? ( Perhaps the fact that systemd has
> already pivoted root to somewhere else?)
Well, the above is not the right way really.
1. If you want to go for the unit option, it is definitely a better
idea to define one that is started at boot (but has ExecStart=
empty and only ExecStop= defined, and uses RemainAfterExit= to
ensure that it stays active even without a process around). Only
that way you can properly order your unit against other shutdown
units.
2. Doing this via a unit means your code is invoked during the first
phase of shutdown, inside the usual dependency tree logic. I figure
you actually want to do this later even, i.e. after all services
are down, after systemd did its killing spree and umount spree and
all that stuff. For that simply drop the binary/script of your
choice in /usr/lib/systemd/system-shutdown/. All files in that dir
that are marked executable are executed right before we'd return to
the initrd/invoke the reboot() syscall. Also see:
systemd-shutdown(8)
3. Note that the scripts in /usr/lib/systemd/system-shutdown/ are
invoked at a time where the root file system itself is still
mounted. This means various weird storage daemons might still be
pinned (think: root on mdraid/LVM/…). Hence, turning off power at
that point is not fully safe nor correct either, except if you know
your setup and know you don't have weird storage. If you want to
cover this generic case too, then you have to use an initrd, make
use of systemd's logic to transition back into the initrd at
shutdown, and invoke what you want to invoke from there.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list