Bug 89503

Summary:	plymouthd startup returns before plymouthd is ready to handle requests
Product:	plymouth	Reporter:	Chris Bainbridge <chris.bainbridge>
Component:	general	Assignee:	Ray Strode [halfline] <rstrode>
Status:	RESOLVED NOTOURBUG	QA Contact:
Severity:	normal
Priority:	medium	CC:	rstrode
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Chris Bainbridge 2015-03-09 13:02:15 UTC

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:

        /sbin/plymouthd --mode=shutdown
        /bin/plymouth show-splash

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:

        /sbin/plymouthd --mode=shutdown
        while ! plymouth --ping; do sleep 1; done
        /bin/plymouth show-splash

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)

Comment 1 Ray Strode [halfline] 2015-03-09 17:21:50 UTC

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?

Comment 2 Chris Bainbridge 2015-03-09 21:14:32 UTC

Upstart doesn't wait for the call to plymouthd to exit, it just waits for it to fork.

The upstart script is like:

    expect fork
    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.

Comment 3 Chris Bainbridge 2015-03-12 02:10:20 UTC

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?

Comment 4 Ray Strode [halfline] 2015-03-12 11:30:44 UTC

Hi,

(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?
Yes.

> Would you consider it a bug in plymouthd?
No.  

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.

Comment 5 Chris Bainbridge 2015-03-12 12:59:05 UTC

Thanks for clarifying.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.