[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

  * 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
    # 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

 This was originally reported in
 Thanks to Colin Watson and others for analysis.

Loïc Minier

Reply to: