Hello, 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 reboot/update). 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). Regards, Norbert _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel