Package: runit
Version: 2.0.0-1
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, Gerrit.  I'm encountering a problem with runit that I'm hoping
you can help me with.

It appears that stopped runsv processes are not responding to TERM
signals.  The big problem that this is causing is that services
removed with update-service --remove do not die:

servo:~ 1$ sudo update-service --add /var/lib/cereal/sessions/foo cereal.foo
Service cereal.foo added.
servo:~ 0$ pidof runsv
27144
servo:~ 0$ sudo svstat /etc/service/cereal.foo
/etc/service/cereal.foo: down 51 seconds
servo:~ 0$ sudo update-service --remove /var/lib/cereal/sessions/foo cereal.foo
Service cereal.foo removed, the service daemon received the TERM and CONT 
signals.
servo:~ 0$ sudo svstat /etc/service/cereal.foo
/etc/service/cereal.foo: unable to chdir: file does not exist
servo:~ 0$ ps -eFH | grep [r]unsv
root      3276     1  0    30    32   0 Oct24 ?        00:00:05   runsvdir -P 
/etc/service log: 
...........................................................................................................................................................................................................................................................................................................................................................................................................
root     27144  3276  0    27    36   0 14:30 ?        00:00:00     runsv 
cereal.foo
servo:~ 0$ pidof runsv
27144
servo:~ 0$ sudo kill -TERM $(pidof runsv)
servo:~ 0$ pidof runsv
27144
servo:~ 0$ sudo kill -KILL $(pidof runsv)
servo:~ 0$ pidof runsv
servo:~ 1$ 

I emphasize that this only seems to be a problem for *stopped*
services, since running services seem to go away fine:

servo:~ 0$ sudo update-service --add /var/lib/cereal/sessions/foo cereal.foo
Service cereal.foo added.
servo:~ 0$ sudo sv start cereal.foo
ok: run: cereal.foo: (pid 26515) 0s, normally down
servo:~ 0$ sudo update-service --remove /var/lib/cereal/sessions/foo cereal.foo
Service cereal.foo removed, the service daemon received the TERM and CONT 
signals.
servo:~ 0$ pidof runsv
servo:~ 1$ 

Any idea what the problem could be?  I only just noticed this today,
so I'm not sure how long this has been a problem.  It definitely
hasn't always been a problem.

Please let me know if there's anything else I can do to help figure
this out.  And thanks, as always, for maintaining such a great program.

jamie.

- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

runit depends on no packages.

Versions of packages runit recommends:
pn  fgetty                        <none>     (no description available)

Versions of packages runit suggests:
pn  runit-run                     <none>     (no description available)
pn  socklog-run                   <none>     (no description available)

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBAgAGBQJJHILrAAoJEO00zqvie6q8iK4P/RHf3/99NDOIxK5fmbW88P1G
/SwrCWyPJzs2cT3EYyOJyE5n2TYmumq5Pd2p8PPLtqme2A4ZX/yzaN39R4ud1rjZ
Meyk+aNNrGKjHCLSUJYakcfVv3gFBoh7aren3e0Je4lAKuvSs6nEMwcyfD9EkXvT
v8+bZBMHrSYVoLJGuUFxuxEKVimaREvJztn2uHnJd8Ior9+ghPekIAruNfyFhV8a
0u/qqi42praHVT2L3Nvjo8IFIM/iRUNX7crK9KIqwXYkvb7+lkSNhjvT4kQabpfo
2N/S4K3i+bDcF/71F/j44R5/5UorjZLejSOZqiIlOhYrBh1paEG0tYdPahjFVNf9
7TkmmONSpHXmTQ6zBHcdjDmnDdQR1qWlnYTHJ1Y40ZE4lfLq3YkIm9KPlNGqDCFM
wl7efrJ1ZzpMQn0yIA6TRfz9d6PwEne98cIYs9XnPmQdt+/1Jr5kp1jKnsb3J+GC
tnuQN5uxPszeiw8j2ijPKHsxyhn4RmUS4aMemHIL8Qu9zWKUHjU5ZEZAaYj/QzQ6
GPQUxXcc0UNKycArWewDQYuLh/OauHtqb37muw++edHgGkvVGG+kOc9TbCr3SEC2
wz/h+lajbtxwv1wK67tZviqhGILDmRYZCWqXaOBuNu/c2ZoLznXgsQuSh48Hgc7e
wPPYmbFBKlzPtJHyVJb1
=vmoy
-----END PGP SIGNATURE-----



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to