Comment 5 for bug 1767760

@ 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.