Comment 45 for bug 966480

Chris, this analysis is unlikely to be correct. Certainly at the time the plymouth upstart jobs were written, plymouthd was only forking once - and correctly opening its socket before detaching from the foreground. If plymouthd behavior has since changed to double fork, and to not start accepting connections until after the first fork, then not only would there be a race condition, but upstart would completely lose all ability to sanely track the plymouthd process - it would consider the plymouth service 'stopped' as soon as the first child had exited.

And considering we're discussing a problem that occurs only on shutdown - there have been no problems with reliability of plymouth splash appearing on boot due to a corresponding race condition - I don't think this is at all a likely explanation for the behavior.

Historically the problems with plymouth not displaying on shutdown from an install image have been due to a race between the plymouth jobs loading the required files into memory, and the casper jobs unmounting the filesystem that these files live on (which is a prerequisite for ejecting a DVD). This bug is almost certainly an instance of this general problem.