-
Poking Around in Upstart
The hack I added to the lightdm startup script occasionally causes it to hang, which suggests a timing problem. The result leaves the default text-mode login screen active on VT1, after which I can log in and issue
sudo lightdm startto produce the usual GUI screen. Usingstartxdoesn’t (seem to) start the display manager, resulting in all manner of weird behavior.The definitive Upstart info seems to be in the Upstart Intro, Cookbook, and Best Practises document.
The stanza I modified looks like this:
start on ((filesystem and runlevel [!06] and started dbus and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 or stopped udev-fallback-graphics) and mounted MOUNTPOINT=/mnt/bulkdata) or runlevel PREVLEVEL=S)According to the timing diagram in section 10.1.8, the
filesystemevent should happen after all the remote filesystems have been mounted, which seems like that stanza might produce a race condition. So just waiting for thefilesystemevent should suffice, but it doesn’t; that’s why I had to add themountedevent.According to the example in section 11.14, that stanza should probably look like:
start on ((filesystem and (runlevel [!06] and (started dbus and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 or stopped udev-fallback-graphics)))) or runlevel PREVLEVEL=S)The additional parentheses around successive conditions seem to serialize them, so that they need not all occur at the same time.
At least I think that’s how it should work…
Unfortunately, it doesn’t. The good news is that it’s converted the intermittent failure into a hard fault, which is generally a step in the right direction.
Changing the stanza to:
#start on ((filesystem start on ((mounted MOUNTPOINT=/mnt/bulkdata and runlevel [!06] and started dbus and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 or stopped udev-fallback-graphics)) # and mounted MOUNTPOINT=/mnt/bulkdata)) or runlevel PREVLEVEL=S)… also fails hard.
At this point, I have no idea what to do, so I’ve restored the original stanza.