Wouter Verhelst <wou...@debian.org> writes:
> On 26-05-13 15:11, Holger Levsen wrote:
>> Hi,
>>
>> On Samstag, 25. Mai 2013, Nikolaus Rath wrote:
>>> For example: after some intense studying, I now fully understand why
>>> declaring a new upstart job C that depends on existing jobs A and B
>>> ("start on job-a-did-its-thing AND job-b-did-its-thing") may prevent the
>>> start of job A (cf
>>> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/964207). However, I
>>> still consider it confusing and at least questionable design that adding a
>>> new job can prevent an existing job from starting even though they do not
>>> conflict in any way.
>>
>> WHAT?!? if that's true then I for sure know what I won't let near my
>> systems!
>> That's rather horrible. Thanks for the info!
>
> Reading the bug, what Nikolaus fails to mention is that the way the
> event handling happens, this really becomes a _circular_ dependency
> unless the --no-wait option is specified (IIUC)
The hang is because of a loop, yes, but this loop doesn't exist in the
actual dependencies:
gdm depends on mountall (via mounted event) and dbus
dbus depends on mountall
There should be no problem at all to satisfy these dependencies and boot
the system. However, due to the event-based way upstart is designed, it
doesn't work like that: if mountall emits its events without --no-wait,
then the emitting the mounted event will "latch" and only return once
gdm is started. gdm, however, still waits for dbus, and the boot hangs.
The only way to avoid this (at least at the time I reported the bug),
would have been to recompile mountall to emit events with --no-wait (but
I'm not sure what other unintended consequences that would have had).
As I said, there isn't a bug anywhere here. Once you understand what's
going on, this all makes sense. But I don't consider this a very good
design.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ndontbu....@vostro.rath.org
