plymouth timeout prevents x-server from correct initialization

[Thomas Schustek]

After upgrading from plymouth_0.9.2-3ubuntu13.3 to plymouth_0.9.2-3ubuntu13.4 about 50% of all x-server initializations failed and Xorg crashed after entering fail-save-mode. A typical reason for this behaviour was that it could not acquire DRM interface /dev/dri/card0 not have been release before by plymouth after a time-out condition.

Downgrading to plymouth_0.9.2-3ubuntu13.3 fixed the issue same as elongating the time-out-interval from 2.0 to at least 6.0 seconds in src/client/plymouth.c.

Ubuntu 16.04.4 is running on a about 9-year-old notebook with an Intel Core 2 Duo U9400 @ 1.4 GHz CPU and a non-solid-state-disk. Its rather complex xkb configuration takes more than a second to compile.

[Thomas Schustek (tho5as)]

As already noted increasing the time-out up to 6.0 seconds works for me.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Increases time-out for plymouth ping" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Brian Murray (brian-murray)]

Thanks for bringing this up and including a patch. Could you provide a test case for us so that we can ensure that the Stable Release Update we provide addresses the issue that you are reporting?

[Thomas Schustek (tho5as)]

@ Brian Murray

Sorry, I am afraid I cannot help you. The referee is my old slowly running notebook with daily updated Ubuntu 16.04 writing a crash report or not on start-up. Furthermore it would be of little use because, first, there may be slower machines out there and, second, increasing the time-out interval does not fix the underlying problem. It is just a quick fix and I posted the file mostly for documentation purposes. Therefore I think I should better withdraw the patch.

As far as I understood the postings on bug report no. 1705345 the plymouth client will hang if the plymouth daemon process has been stopped before – whatever the reason was for the latter. So only the calling process (e.g. a package post-installation-script) knows how to handle a situation with a started but inactivated plymouth daemon which may have allocated system resources before or may get in trouble when continuing after a re-configuration of parts of the system has been done.

In my opinion the best solution would be that every plymouth ping request gets preceded by a check for the plymouth daemon's pid file and for the daemon's process status by the calling process. Doing these tests within the plymouth client would actually prevent it from getting stuck but also will lead to ambiguous results if its exit value is getting tested for being true or false only.

Concerning my Ubuntu implementation I can hardly imagine a reason for the plymouth daemon to get stuck during system start-up for more than 5 seconds other than a hardware issue. Maybe the complex hard disk layout with 17 partitions (Most of them are NTFS-formatted and one of these gets auto-mounted by the system.) causes a delay of several seconds in the system bootstrap process.

The complex xkb configuration can be ruled out because there is no xkb-based console setup. As far as I have seen plymouth keyboard input translation is based on static default console setup in /etc/console-setup/cached.kmap.gz.