On 27/10/17 12:25, Lennart Poettering wrote: > On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel