[Pkg-sysvinit-devel] Bug#699523: sysvinit: postinst fails if several 'init' process are running (LXC)

Roger Leigh rleigh at codelibre.net
Fri Feb 1 16:13:34 UTC 2013


On Fri, Feb 01, 2013 at 10:19:14AM +0100, Cyril Bouthors wrote:
> I can't upgrade to latest sysinit because the initscript fails:
> + pidof /sbin/init
> + PID=3164 3141 3118 1
> + kill -s USR1 3164 3141 3118 1
> /var/lib/dpkg/info/sysvinit.postinst: 41: kill: Illegal number: 3164 3141 3118 1
> 
> $PID contains multiple PIDs because several 'init' process are running on the
> machine on distinct LXC containers:
> 
> % ps -C init  
>   PID TTY          TIME CMD
>     1 ?        00:00:04 init
>  3118 ?        00:00:02 init
>  3141 ?        00:00:02 init
>  3164 ?        00:00:02 init
> 
> % pidof init
> 3164 3141 3118 1
> 
> I see several ways to fix this issue:
>  - killall -s USR1 init
>  - for pid in $PID; do kill -s USR1 "$PID"; done

These two approaches will work, but will send them to all "/sbin/init"
processes.  These might not necessarily be sysvinit, and might kill
your system.  Concrete example: Hurd which doesn't have init as PID 1
(it's something else) and more importantly upstart, which replaces
sysvinit (though I think it conflicts so this should be a non-issue).

>  - PID="$(pidof -s init)"

This might still get us the wrong PID.

>  - a check on the number of process based on 'pgrep -c init'

This might not be any more robust either; depending upon the
selection criteria.

> Which way is the best?

They all look equally bad, IMO.  We really want the PID of the
init process in our current namespace, and we want to work
correctly whether we are inside or outside a container.

In the example you gave above, what is the difference between
"pidof /sbin/init" on the host and in each container.  What if
"-s" is used?

sudo lsof | grep initctl
init          1              root   10u     FIFO               0,14       0t0       3085 /run/initctl

What do you see for this on the host and in the containers?

This is more reliable.  It restricts us to processes having the
control channel open.  But... we still have the question of which
control channel is the correct one when we have namespaces.  And
if the channel is unlinked, we still need a fallback.

> I hope to see this issue fixed.

Likewise, but not using LXC I will need help to do so.  The main
question is how to get the correct PID here out of the several
candidates, and to behave correctly cross-platform.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



More information about the Pkg-sysvinit-devel mailing list