[systemd-devel] Scheduling unit at reboot.target and shutdown.target

[D.S. Ljungmark]

On 27/10/17 12:25, Lennart Poettering wrote:
> 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



Since this is an embedded case, we have fairly good control over what's
running and where.  For example, rootfs is not a problem as it's
squashfs, and shouldn't be degraded by rebooting.  As long as our
configuration/data partitions aren't mounted, we ought to be good.

And thank you for the pointer about /usr/lib/systemd/system-shutdown/
that indeed sounds a lot better for us.

ExecStop does indeed sound like the wrong solution as well, as mentioned
due to the ordering.


Thanks for the thorough explanation, much appreciated!

//D.S.