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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/964207
Title:
Dependency loops due to ANDed start conditions leave system unbootable
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/964207/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
