I suggest first porting microupsd itself to a native systemd .service file (so that it'll have process monitoring and everything). That might even fix part of the problem.
Normally services are given a certain amount of time to stop after SIGTERM (or whatever KillSignal was set, or whatever ExecStop command was specified). Even if microupsd doesn't handle SIGTERM nicely (which I'd call a bug), it's possible to add some... arbitrary delays. Units are stopped due to having automatic Conflicts=shutdown.target, if I remember correctly. I'm not sure if disabling that default dependency is a good approach though... This time I can't think of a good combination that'd solve both problems without introducing some ugly race conditions... On Tue, Aug 8, 2017, 21:46 Marek Floriańczyk <marek.florianc...@gmail.com> wrote: > Dnia wtorek, 8 sierpnia 2017 21:04:18 CEST Andrei Borzenkov pisze: > > 08.08.2017 17:03, Marek Floriańczyk пишет: > > > What would be the proper way to distinguish between system is going > down > > > for reboot and for shutdown ? > > > > Straightforward way is to make your service WantedBy poweroff.target and > > halt.target. You can then have second service WantedBy reboot.target and > > kexec.target. They may even call the same binary (script) but with > > different arguments. > > Thanks for answer, > > So, my binary "microupsd" is started by /etc/init.d/microups at the boot > time > to monitor power input, battery status etc. > During system halt I need to send SIGUSR1 to this "microupsd" process at > which > it will send command to microups device, moreover I would like to give it > some time (like 1-2 seconds) to accomplish the transmission. > I don't need to send anything in case of reboot. > > Should I prepare some script that sends SIGUSR1 to "microupsd" process and > then sleeps for 2 seconds and set it as WantedBy poweroff.target and > halt.target ? > > How can I be sure that this script will be called before "microupsd" is > actually killed during system shutdown ? > > Best Regards > Marek > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Mantas Mikulėnas <graw...@gmail.com> Sent from my phone
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel