Fully updated Fedora 16 running on a dual Xeon machine. (w/ nVidia binary drivers). plymouthd consistently hangs when I reboot into init 5 with __epoll_wait_nocancel eating 100% CPU. epoll is being called by the following code (ply-event-loop.c:1368): 1368 while (!loop->should_exit) 1369 ply_event_loop_process_pending_events (loop); When I kill plymouth/d, systemd starts X, without any noticeable issues. - Gilboa
(In reply to comment #0) > ... plymouthd ... eating 100% CPU. .... I have observed similar symptoms with: plymouth-0.8.4-0.20110822.3.fc16.i686 Linux version 3.2.7-1.fc16.i686 Integrated Graphics Chipset: Intel(R) 945G Twice (out of ~six boots) the system has hung before fully painting white the last little sliver in the upper right quadrant of the circle that would turn into the fedora logo. The first time this happened was the first boot following Updates. I eventually was able to use Ctrl+Alt+F2 and see a login prompt, then "top" revealed plymouthd was consuming 100% CPU. Since there was not evidence of e.g. a SELinux filesystem relabel or other post-Update work still in progress, from the command line "shutdown now" provided an escape. The next boot promptly proceeded to the graphical login. The second time this happened, Ctrl+Alt+F2 never revealed anything but a flashing cursor, even after a half-hour of patience. (During the first occurrence, there had been a delay of at least several minutes before the a login prompt replaced the flashing cursor on the tty.) So I merely assume (rather than having evidence via "top") that plymouthd was at fault once again. Lacking both a graphical login prompt or a command line prompt, I guessed that Ctrl+Alt+Del might be a safer escape than merely pressing the power button. After the next system boot proceeded promptly and normally, one can see in /var/log/messages that chronyd and systemd-tmpfiles left a few lines during that useless half-hour, but no error messages before or after to hint at what went wrong. Advice on what to attempt to observe if similar symptoms should appear again? Nelson
I experience the same, is there any place where I can see debug messages?
if you add plymouth.debug=stream:/dev/kmsg then you should get a log in "dmesg" output.
Created attachment 607444 [details] First hang In this hang I've plugged an USB Keyboard after the hang, but nothing changed.
Created attachment 607445 [details] Second hang There are audit messages that look suspicious.
This may be a bug in KDM (well if plymouthd is taking up 100% cpu, that's obviously also a bug). It calls plymouth deactivate, but never seemingly calls plymouth quit.
Rex, is there any sort of debug log KDM can produce?
$ kdm --help Usage: kdm [options] [tty] -daemon - Daemonize even when started by init -nodaemon - Do not daemonize even when started from command line -config <file> - Use alternative master configuration file -xrm <res> - Override frontend-specific resource -error <file> - Use alternative log file -debug <num> - Debug option bitfield: 0x1 - core log 0x2 - config reader log 0x4 - greeter log 0x8 - IPC log 0x10 - session sub-daemon post-fork delay 0x20 - config reader post-start delay 0x40 - greeter post-start delay 0x80 - do not use syslog 0x100 - core Xauth log 0x200 - debug greeter theming 0x400 - valgrind config reader and greeter 0x800 - strace config reader and greeter looks like prefdm will pass options on to the DM of choice. not sure how to get the prefdm.service to pass the appropriate -debug flag to log more stuff to /var/log/kdm.log looking closer at the plymouth-related code in kdm, kde-workspace-.../kdm/backend/server.c has the following: void startServerSuccess() { struct display *d = startingServer; d->serverStatus = ignore; serverTimeout = TO_INF; if (d->plymouth_is_running) { debug( "Quitting Plymouth with transition\n" ); d->plymouth_is_running = !plymouth_quit_with_transition (); debug ("Is Plymouth still running? %s\n", d->plymouth_is_running ? "yes" : "no"); } debug("X server ready, starting session\n"); startDisplayP2(d); } so adding the debug statements should hopefully make it crystal-clear what is going on indeed.
Paulo can you edit /etc/X11/prefdm to add the -debug 0x7 or so?
Ray, I've added, now I need to wait for the bug occurs. It's random on my pc, so I do not have a way to replicate, but it happens sometimes.
Doing the same. However, as the bug is rather rare (twice since the release of F17) and given the fact that I rarely reboot machines, it'll take while. Adding -debug to preferred in prefdm. - Gilboa
So it happened again, now with debug 0x7 active. I will upload the dmesg as dmesg2.gz and kdm logs.
Created attachment 609610 [details] dmesg2 after setting debug flag
Created attachment 609611 [details] kdm.log with debug active
actually i think this is really just: http://cgit.freedesktop.org/plymouth/commit/?id=ecd2721f1e83b149a3ef24ad88aa6e32f622d129
plymouth-0.8.4-0.20110822.6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/plymouth-0.8.4-0.20110822.6.fc16
I've built a test update, please give it a whirl. (remember to rebuild the initrd with dracut -f after installing it)
Package plymouth-0.8.4-0.20110822.6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing plymouth-0.8.4-0.20110822.6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13477/plymouth-0.8.4-0.20110822.6.fc16 then log in and leave karma (feedback).
I'm sorry, only after seeing the last comment, I've found this bug was assigned to F16, while in fact I'm running F17.
plymouth-0.8.5-0.2012.04.27.3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/plymouth-0.8.5-0.2012.04.27.3.fc17
plymouth-0.8.4-0.20110822.6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
plymouth-0.8.5-0.2012.04.27.3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.