Bug 798684 - Random delay on Fedora shut-down
Random delay on Fedora shut-down
Status: CLOSED DUPLICATE of bug 739836
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-02-29 10:09 EST by Saurav Sengupta
Modified: 2012-03-02 06:56 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-02 06:56:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg debug output for delayed shut-down (268.42 KB, text/plain)
2012-03-02 06:45 EST, Saurav Sengupta
no flags Details

  None (edit)
Description Saurav Sengupta 2012-02-29 10:09:52 EST
Description of problem:
A delay occurs randomly during the shut-down process of Fedora, for both turning off the system and for rebooting. I read a statement somewhere that a delay occurs when the shut-down process is invoked too soon after start-up. As far as I can check, this appears to be true. Shutting down after a significant amount of time after start-up does not cause the delay. Pressing Esc during shut-down to hide the Plymouth screen and see the messages does not show anything abnormal, except the "write cache" message as reported in bug no. 769747, but I do not know if that bug is related to this issue. This delay can be found reported in some forums, etc., which appear in a Google search, but I could not find any report in Bugzilla, and neither could I find any solution or workaround.

Version-Release number of selected component (if applicable):
14 to 16, although it may still be in 17 and/or Rawhide.

How reproducible:

Steps to Reproduce:
1. Start a Fedora desktop system and log in.
2. Turn off the system using the desktop menu, very few seconds after logging in.
Actual results:
A significant delay occurs before the system turns off.

Expected results:
The system turns off in that amount of time that it requires when shutting down normally after several minutes of logging in. In other words, the shut-down process should finish within a few seconds.

Additional info:
Comment 1 Saurav Sengupta 2012-02-29 10:12:18 EST
The delay also often occurs after a YUM operation, such as installing or updating packages.
Comment 2 Michal Schmidt 2012-03-01 10:34:18 EST
What does the command "systemctl list-jobs" print immediately after logging in?
Comment 3 Saurav Sengupta 2012-03-01 14:47:42 EST
Nothing. 0 jobs listed.
Comment 4 Saurav Sengupta 2012-03-01 15:58:22 EST
I have also confirmed that the delay sometimes occurs even a long time after login. However, I am unable to find any particular usage pattern that causes it.
Comment 5 Michal Schmidt 2012-03-01 19:08:19 EST
Save this script as /lib/systemd/system-shutdown/debug.sh:

mount / -o rw,remount
dmesg > /dmesg.txt
mount / -o ro,remount

Make it executable (chmod +x /lib/systemd/system-shutdown/debug.sh).

Then boot with the following kernel command line parameters:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0

Reproduce the delay on shutdown.
After booting back, attach the resulting /dmesg.txt file here. Thanks.
Comment 6 Saurav Sengupta 2012-03-02 04:48:04 EST
OK, I'll do this and report back. If I can get a delay after a short session, well and good, otherwise I don't know when I'll be able to get a delay, because of the random nature of the problem.
Comment 7 Saurav Sengupta 2012-03-02 06:45:17 EST
Created attachment 567038 [details]
dmesg debug output for delayed shut-down
Comment 8 Saurav Sengupta 2012-03-02 06:50:35 EST
I have attached the dmesg output from a delayed shut-down. I have also kept a copy of the output from a normal shut-down. I can provide that too, and/or a diff, if you want.
Comment 9 Michal Schmidt 2012-03-02 06:56:47 EST
NetworkManager did not quit after SIGTERM and was killed by SIGKILL after a timeout of 90 s.

*** This bug has been marked as a duplicate of bug 739836 ***

Note You need to log in before you can comment on or make changes to this bug.