OpenVZ and the Ubuntu Upstart init daemon

[Daniel Pittman]

Scott James Remnant <scott at ubuntu.com> writes:
> On Sat, 2007-04-07 at 23:20 +1000, Daniel Pittman wrote:
>
>> > G'day.  I have been playing with the 'upstart' daemon that replaces
>> > the traditional /sbin/init process in Ubuntu Edgy and Feisty.

[...]

> This was a bug introduced relatively recently while clearing out the
> main() function, and has already been fixed in bzr trunk:
>
> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%
> 40netsplit.com-20070313191319-gztu8c0r0sjla0hp?start_revid=scott%
> 40netsplit.com-20070316171800-scmrd6w9r22uf4me
>
> I've had reports of OpenVZ failing for some time before this though;
> can you confirm that with this patch, Upstart works correctly?

OK: with the patch for the file descriptor bug fixed and a version of
upstart compiled with it in place I have successfully started Ubuntu
6.10 in an OpenVZ VE.


My initial testing wasn't as positive: with upstart diverted to
/sbin/init.distrib and a shell script in place that would start syslogd
at the very start of the boot process Upstart was unable to detect the
end of the rcS event.[1]

Once I removed the diversion, putting the real binary back as /sbin/init
it was able to detect the termination of the process correctly and, as a
result, entered runlevel 2.


That makes it *almost* enough to boot Ubuntu Feisty in a VE:

The one remaining problem is that /etc/init.d/mountall.sh on line 74
issues the command:

    kill -USR1 1

That causes /sbin/init to terminate under OpenVZ; replacing USR1 with
TERM allows Feisty to fully boot.

Now, I took a look through the source code for Upstart and this looks
like it might be an Upstart issue -- or, at least, an environmental
difference between the VE and the real kernel init process.


The only reference to USR1 in the init code seems to be the
nih_signal_reset function, installing the default signal handler.

The default for USR1, by signal(7), is to terminate the process.

The traditional Linux SYSV init handled USR1 as the "reload
configuration" signal -- which is why it is (presumably) still sent by
the init scripts.


I can only presume that when init is running as PID 1 on the native
kernel it is automatically protected from SIGUSR1 termination -- and
that OpenVZ doesn't provide the same protection.

Without that assumption I can't explain how upstart manages to boot
successfully on the bare hardware.


Anyway, a few things:

Am I correct in my assumption -- should I take this issue of protection
from signals up with the OpenVZ developers so they extend the same magic
to the virtual PID 1 that the real PID 1 gets?


I think that SIGUSR1 should probably be handled by upstart anyway, to
implement the compatibility "reload configuration" option as needed.

Finally the SYSV compatible init scripts may want to adapt their actions
to be more realistic about the running init process -- if they are
forced to upstart in Feisty they should probably use the native signal
structure.


Anyway, once that issue is addressed -- I edited the script and changed
USR1 to TERM -- Feisty will "boot" correctly in a stock OpenVZ VE.

So, once the correct response to the signal issue is determined and the
changes to the file descriptor management are published (revision 677)
you could close Launchpad bug #87173.

Regards,
        Daniel

Footnotes: 
[1]  The script was:

#!/bin/sh
if [ "$$" = "1" ]; then /sbin/syslogd; fi
exec $0.distrib "$@"

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/