On Sun, Apr 14, 2019 at 10:52:42AM +0000, Dmitry Bogatov wrote: > [2019-04-12 01:32] Mathieu Mirmont <m...@parad0x.org> > > [...] > > I believe this bug will be fixed as effect of #924769 (not marked as > resolved, due my typo in changelog), which is now in Archives as > runit=2.1.2-28/experimental. With #924769 in effect, runscript will stop > init.d instance before starting its own. Mind to check?
Yes that fixes the bug indeed, thanks. Generally speaking, for packages that use dh_runit I suppose that it is fine because the order of execution in the postinst script is deterministic: the init.d script will always be started first. Hopefully this is by far the most common case. It is quite brittle to rely on a side effect of how the postinst files are generated though, but without invoke-rc.d or the init.d script being aware of runsvdir I don't see a simple solution that would be guaranteed to work everywhere, unfortunately. > > I suspect that a fix could be implemented in invoke-rc.d by making it > > aware of runsvdir, similarly to how it is already aware of systemd and > > openrc? > > Yes, it is planned, but pushing changes to init-system-helpers is quite > long and painful process for me for social reasons. If you are willing > to help, you are more then welcome. Hmm.. I'm generally happy to help, but not very much really looking forward to long and (socially) painful processes. > Take a look at #924132. Interesting, though quite a number of changes. I only quickly looked at the sources, I'll have a better look at it at some point. I am hoping that there is a simpler solution out there. One issue I notice is that it only considers runit services if runit is the init system (by looking for /run/runit.stopit). However runsvdir can also be run under sysvinit and systemd. -- Mathieu Mirmont <m...@parad0x.org>
signature.asc
Description: PGP signature
