Bug#608903: Causes reboot of d-i if installing with upstart
Package: eglibc
Version: 2.11.2-3
Severity: normal
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch natty
Hey there
In eglibc 2.11.2-3, debian/debhelper.in/libc.postinst was changed
roughly like this:
- if [ "`uname -s`" = Linux ]; then
- if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then
- # the devicenumber/inode pair of / is the same as that of /sbin/init's
- # root, so we're *not* in a chroot
- (telinit u ; sleep 1)
- fi
- fi
+ # Restart init. If it fails, there is nothing we can do, so.
+ #%just ignore the error
+ telinit u 2> /dev/null || true ; sleep 1
changelog:
* Always try to restart init when needed, and ignore the possible errors.
Closes: #588922, 590175.
When telinit in the chroot is upstart's telinit, it will send SIGTERM
to PID 1 to signal an upstart instance to reexec itself.
Unfortunately, busybox when used as /sbin/init (as is the case under
d-i) will reboot when it receives a SIGTERM.
While we probably want to change upstart to check whether PID 1 really
is an upstart instance and not busybox, I also believe we should re-add
the chroot check in libc.postinst as I don't think we need to restart
init in this case. I propose replacing the postinst snippet with this
one:
# try to restart init, unless in a chroot (may only be tested under Linux);
# the chroot test is important in the case of e.g. d-i using busybox as
# /sbin/init and installing upstart in a chroot: upstart's telinit sends
# init a SIGTERM and busybox reboots on SIGTERM
if [ "`uname -s`" != Linux ] || [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ]; then
# we ignore errors because there is nothing we can do if that fails,
# and some weird/broken environments (e.g. no /dev/initctl but a
# telinit expecting one) fail to run "telinit u"
telinit u 2>/dev/null || true
sleep 1
fi
This was originally reported in
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/694772
Thanks to Colin Watson and others for analysis.
Cheers,
--
Loïc Minier
Reply to: