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 start to produce the usual GUI screen. Using
startx doesn’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
filesystem event should happen after all the remote filesystems have been mounted, which seems like that stanza might produce a race condition. So just waiting for the
filesystem event should suffice, but it doesn’t; that’s why I had to add the
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.