Bug 798684

Summary: Random delay on Fedora shut-down
Product: [Fedora] Fedora Reporter: Saurav Sengupta <sauravsengupta17>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: dennis, johannbg, metherid, mschmidt, notting, plautrba, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-02 11:56:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg debug output for delayed shut-down none

Description Saurav Sengupta 2012-02-29 15:09:52 UTC
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:
Usually

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 15:12:18 UTC
The delay also often occurs after a YUM operation, such as installing or updating packages.

Comment 2 Michal Schmidt 2012-03-01 15:34:18 UTC
What does the command "systemctl list-jobs" print immediately after logging in?

Comment 3 Saurav Sengupta 2012-03-01 19:47:42 UTC
Nothing. 0 jobs listed.

Comment 4 Saurav Sengupta 2012-03-01 20:58:22 UTC
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-02 00:08:19 UTC
Save this script as /lib/systemd/system-shutdown/debug.sh:

#!/bin/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 09:48:04 UTC
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 11:45:17 UTC
Created attachment 567038 [details]
dmesg debug output for delayed shut-down

Comment 8 Saurav Sengupta 2012-03-02 11:50:35 UTC
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 11:56:47 UTC
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 ***