Description of problem: I always get a 5 seconds delay between Sending SIGTERM to remaining processes... and Sending SIGKILL to remaining processes... when I reboot my F16 VM. The 5 s is the maximum time systemd is willing to give the processes to exit cleanly after sending them SIGTERM. It is not expected that this timeout would be reached under normal circumstances, because most processes exit quickly. systemd can detect when no more processes are remaining. After adding some debug prints into systemd I found that the only process not exiting after SIGTERM is plymouthd. I confirmed this also by masking out plymouth-reboot.service and verifying that the 5 s delay no longer occurred. This plymouth commit is to blame: http://cgit.freedesktop.org/plymouth/commit/?id=841068ba125f30fedd52b62490c6a7424b30c768 Hang around until killed by init at shutdown init does two rounds of killing at shutdown: a round of SIGTERMs and a round of SIGKILLs. We want to stay alive until the SIGKILL round so we ignore the SIGTERM signal. This assumes that init does a constant-time sleep between sending SIGTERM and SIGKILL. This is not true with systemd. systemd can detect when there are no more processes to wait for and cut the waiting. By ignoring SIGTERM, plymouthd makes this optimization impossible and forces systemd to always wait the maximum time (5 s). Please revert the commit. Version-Release number of selected component (if applicable): plymouth-0.8.4-0.20110822.2.fc16.x86_64 systemd-36-3.fc16.x86_64
From #systemd: <halfline__> michich: i think reverting the patch makes sense, but we actually need to do more than just revert patch <michich> halfline__, any way I can help? <halfline__> michich: the whole reason plymouth needs to stick around is because the kernel will automatically switch back to the fb console when plymouth dies if using drm apis <halfline__> so what we need to do is <halfline__> pass the handle to the fb being used by plymouth to systemd <halfline__> so it doesn't go away when it's automatically unreffed at plymouth exit time <halfline__> then plymouth can get the splash to a good end frame and leave without worry about the screen blinking back to text <halfline__> so to fix this right we really need more protocol added and more integration with plymouthd <halfline__> s/plymouthd/systemd/ <michich> interesting <halfline__> i'm assuming we could just pass the open fd right over the socket to systemd and systemd could just hold on to it <halfline__> and things will just work <halfline__> needs testing though <halfline__> we definitely don't want systemd linking to the various libdrm libraries, though <halfline__> so hopefully the fd passing will be enough
Thanks for fixing this upstream: http://cgit.freedesktop.org/plymouth/commit/?id=488a5d65788022c50987d57f3a1e598c2bff6382 Is there going to be a Fedora update?
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.