[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