| Summary: | systemd timeout delay during most shutdowns - journald suspected | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Frank Griffin <ftg> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | bittwister2 |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | systemd | CVE: | |
| Status comment: | |||
|
Manuel Hiebel
2013-01-21 22:51:21 CET
Assignee:
bugsquad =>
mageia This is still happening in cauldron. However, it may be that the journald message results simply because systemd normally leaves journald shutdown for last, but the SysRq-E hits it early, along with whatever is really blocking shutdown. Colin, are the shutdown messages hardened anywhere that they could be found on a subsequent boot ? (In reply to Frank Griffin from comment #1) > However, it may be that the journald > message results simply because systemd normally leaves journald shutdown for > last, I have played with this a little bit and found out you can cause the problem by flushing the logs and restarting journalctl before reboot. my last attempt at trying to get clean logs in my new_boot_logs script is: _log_dir=/var/log/journal/$(cat /etc/machine-id) if [ -e $_log_dir ] ; then for i in 1 2 ; do /bin/rm -f $_log_dir/*@* /bin/rm -f $_log_dir/*~ systemctl kill --signal=SIGUSR2 systemd-journald.service /bin/rm -f $_log_dir/*@* /bin/rm -f $_log_dir/*~ /bin/rm -f $_log_dir/user-* done systemctl restart systemd-journald.service sleep 1 chown root:adm $_log_dir/* fi reboot CC:
(none) =>
junk_no_spam Does this still happen in Mageia 4 and 5? Keywords:
(none) =>
NEEDINFO I haven't noticed abnormally long shutdowns on any of my Cauldron machines for a while now. There are still timeout-tye delays, but they're reasonable now. Closing. Status:
NEW =>
RESOLVED |
During shutdowns on both my cauldron desktop and laptop, shutdown appears to hang. If I ESC outof the plymouth screen, the last message shwing is saying that systemd is sending the shutdown signal to all processes. This has been happening for a while now. It's not a hard hang, as it will eventually time out and shut down. But the only way I could previously kill the hang was with SysRq-E, which resulted in an unreadable flurry of messages on the tty and an immediate shutdown. Now, something's changed, and SysRq-E causes a little bit of activity before something else goes into a timed wait. Hitting SysRq-E gives: systemd-journald - SIGTERM received journald.service holdoff timeout, scheduling restart and this stays on the tty for several seconds before there's anoth flurry of activity and the shutdown takes effect. So I'm guessing that journald is somehow involved in a dependency loop where other services are blocked in shutdown by it, but it is probably waiting for all other services to come down so their termination can be recorded.