Regarding this bug: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/966480
The problem is that the Ubuntu plymouthd init script does the equivalent of:
The second command would fail because of the race condition where plymouthd forks and returns, but isn't actually ready to answer connection requests.
The simple fix would be to modify the init script to wait until plymouthd is ready:
while ! plymouth --ping; do sleep 1; done
But does this make sense?
Should plymouthd really be returning before it is ready to answer requests?
It seems like this behaviour could cause bugs on other non-Ubuntu distributions too (e.g. bug #39774 looks the same)
So this bug report doesn't seem right to me. The code doesn't call ply_detach_daemon (which exits the parent) until after ply_boot_server_listen. Are you sure you've pegged the problem right? If so, can you explain the race to me in more detail?
Upstart doesn't wait for the call to plymouthd to exit, it just waits for it to fork.
The upstart script is like:
exec /sbin/plymouthd --mode=shutdown
post-start exec /bin/plymouth show-splash
afaics upstart starts plymouthd, and when plymouthd forks, upstart then immediately executes "plymouth show-splash". At this point plymouthd isn't ready - race condition - which causes the splash screen to fail.
"The daemon should ensure that when it completes the (second) fork that it is fully initialized, since Upstart uses the fork count to determine service readiness" http://upstart.ubuntu.com/cookbook/#daemon-behaviour
This is probably more the fault of the upstart script than of plymouthd. It seems like it will be easier to just fix the script.
main.c forks before opening the listening port (calls ply_create_daemon before start_boot_server). Is this intentional? Would you consider it a bug in plymouthd?
(In reply to Chris Bainbridge from comment #3)
> main.c forks before opening the listening port (calls ply_create_daemon
> before start_boot_server). Is this intentional?
> Would you consider it a bug in plymouthd?
Upstart should wait until the parent exits. We exit the parent when plymouthd is ready. It must have a way of coping with this situation, since it's not a novel or exotic way to daemonize.
Thanks for clarifying.