2021-04-18 10:01:41 UTC
My setup is some embedded system without logind, running a service
that should be able to poweroff, reboot or reboot-and-update.
Generally I guess this also includes triggering further services
programmatically fron another.
1) As I do currently: send SIGRTMIN+5 to PID1
(not really the complete solution, would need to discern between
2) exec 'systemctl start reboot.target'
basically a variant of 1).
3) Same thing as 2), but do it with dbus or varlink.
4) Some unknown and likely not existing configuration of unit files.
doing something like "IfExitCode=121 then start reboot.target"
5) Use the Watchdog and let it expire.
While working, I would expect the first 3 options to be depended on
various level of rights to interfere with
PID1, aswell as being systemd specific (using dbus or systemd DSO).
Some sort of separation between
advertising the need for reboot and acting on it would be cleaner (ie.
hooking it up in service files).
What are the best option(s) here?
I thought about creating a service that waits on a PathExists (within
the runtime directory of the potentially isolated service),
then executing the reboot command (2), ideally after the service
finished (using Conflicts and After, but that also means the runtime
directory and PathExists file will be gone).