[Bug 964207] Re: Waiting for "mounted MOUNTPOINT=/home" in gdm.conf breaks system boot

[Nikolaus Rath]

Ok, here's my theory of what happens:

I noticed that if you have a very simple upstart job:

# cat /etc/init/test.conf
start on niko-a and niko-b
script
    sleep 10
end script

and then emit niko-a without --no-wait:

# initctl emit niko-a

then this call blocks until niko-b is emitted as well.

Now if mountall tries to emit the mounted event without --no-wait as
well, this would block, because GDM is still waiting for other events
before it can start (e.g. dbus or drm-device-added). However, these
events cannot be emitted until mountall has finished, which it can't,
because it's waiting for GDM to start.

I don't know if this is a bug in upstart (that should somehow accomodate
such chains caused by ANDed starting conditions) or mountall, because it
should not wait for the events to be processed.

(Tested on Ubuntu 10.04)

** Summary changed:

- Waiting for "mounted MOUNTPOINT=/home" in gdm.conf breaks system boot
+ Dependency loops due to ANDed start conditions leave system unbootable

** Also affects: mountall (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: mountall (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/964207

Title:
  Dependency loops due to ANDed start conditions leave system unbootable

Status in “mountall” package in Ubuntu:
  Confirmed
Status in “upstart” package in Ubuntu:
  Confirmed

Bug description:
  If /home is mounted on a separate partition, and the gdm start
  condition in /etc/init/gdm.conf is modified to include "mounted
  MOUNTPOINT=/home" as follows:

  start on (filesystem
            and mounted MOUNTPOINT=/home
            and started dbus
            and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                 or stopped udevtrigger))

  then a lucid system will no longer boot. It seems that in this case
  the mountall process is waiting for input from upstart, but upstart is
  not sending anything. Thus, the required muntall events are not
  emitted and the system refuses to boot.

  The problem can be worked around by manually starting another mountall
  instance while the first instance is hanging.

  I have attached the --verbose output of the first and second mountall, as
  well as an strace output.

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: mountall 2.15.3
  ProcVersionSignature: Ubuntu 3.0.0-17.30~lucid1-server 3.0.22
  Uname: Linux 3.0.0-17-server x86_64
  Architecture: amd64
  Date: Sat Mar 24 18:45:46 2012
  ProcEnviron:
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: mountall

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/964207/+subscriptions