On Sat, Mar 01, 2008 at 02:09:07PM -0800, Larry Doolittle wrote:
> The runit-1.8.0-3 changelog includes
> * debian/runit.preinst, debian/runit.postinst: move away from /var/service/
> to /etc/service/; restart runsvdir; retain backward compatibility symlink
> /var/service -> /etc/service until rdepends have adopted (#461478).
> which presumably triggers the effect I saw.
Yes, you're completely right, due to this transition, the postinst
script sends (as final task) a SIGHUP to the running runsvdir, causing
it to send TERM to all runsv processes it monitors and exit. It'll then
be restarted by pid 1 with /etc/service as argument.
> I was able to complete the upgrade by performing it from a console
> that is not managed by runit.
Great. I'm not sure how it happened that no runit-supervised service
were running on your system. I understand that X might be taken down,
but all the services should be re-activated afterwards. -3 had the
problem you've seen, but I thought I fixed it in -4.
> Whatever strategy is adopted for making this transition needs to
> deal more gracefully with the possibility that apt/dpkg are run
> from a process that will be terminated by a blanket runsvdir restart.
> In my case I use getty's managed from runit, and X via startx from
> there. Other usage patterns will be different -- how about a console
> started from sshd managed by runit, or {g,w,x}dm started from runit?
I tested through a console login and through ssh login, that worked fine
for me. The services got the TERM signal, but for ssh this doesn't
affect currently established connections, and a local login shell
ignores the TERM. I now tested gdm managed through runit, and can
reproduce the problem that X gets stopped while the runit upgrade. Not
good.
Maybe I shouldn't restart runsvdir at all, keep the /var/service ->
/etc/service compatibility symlink forever on upgraded systems. Those
systems get rebooted eventually, and then have runsvdir running in
/etc/service/ as it should.
Thanks for your good problem report, Gerrit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
