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>

> 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

Reply via email to