This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 870744 - systemd fails to cleanly shutdown
systemd fails to cleanly shutdown
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-28 08:04 EDT by Ian Chapman
Modified: 2013-08-01 05:14 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 05:14:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Shutdown log as obtain by following: http://freedesktop.org/wiki/Software/systemd/Debugging#Diagnosing_Shutdown_Problems (13.65 KB, text/plain)
2012-10-28 08:07 EDT, Ian Chapman
no flags Details
Contents of /etc/default/grub (538 bytes, application/octet-stream)
2012-10-28 08:08 EDT, Ian Chapman
no flags Details
Output of systemctl after a boot (3.75 KB, application/bzip2)
2012-10-28 08:11 EDT, Ian Chapman
no flags Details
Contents of /etc/fstab (1.77 KB, application/octet-stream)
2012-10-28 08:12 EDT, Ian Chapman
no flags Details
Shutdown log - lvm2 monitor enabled (244.19 KB, text/plain)
2012-10-30 09:01 EDT, Ian Chapman
no flags Details
Shutdown log lvm2 monitor disabled (244.42 KB, text/plain)
2012-10-30 09:16 EDT, Ian Chapman
no flags Details

  None (edit)
Description Ian Chapman 2012-10-28 08:04:56 EDT
Description of problem:

When issuing a reboot or a shutown, the system always fails to reboot or shutdown properly. It varies. Sometimes I can force it to if I repeatedly press Ctrl-Alt-Delete, sometimes if I leave it for 5 minutes or so it will eventually shutdown. Other times it will sit there with an almost blank screen and do nothing and other times it will will repeatedly spam the same message over and over again. Usually I briefly see a whole bunch of messages about conflicting jobs or dependencies not met for shutdown and so on.

Version-Release number of selected component (if applicable):

systemd-44-20.fc17.x86_64

How reproducible:

Simply reboot or shutdown the system


Steps to Reproduce:
1. reboot
2.
3.
  
Actual results:

The system fails to shutdown or reboot cleanly.

Expected results:

The system should cleanly shutdown the services and reboot or poweroff.

Additional info:
Comment 1 Ian Chapman 2012-10-28 08:07:09 EDT
Created attachment 634508 [details]
Shutdown log as obtain by following: http://freedesktop.org/wiki/Software/systemd/Debugging#Diagnosing_Shutdown_Problems

Shutdown log file as obtain from the advice on this website

http://freedesktop.org/wiki/Software/systemd/Debugging#Diagnosing_Shutdown_Problems
Comment 2 Ian Chapman 2012-10-28 08:08:44 EDT
Created attachment 634509 [details]
Contents of /etc/default/grub

Contents of /etc/default/grub showing the boot up kernel parameters
Comment 3 Ian Chapman 2012-10-28 08:11:21 EDT
Created attachment 634510 [details]
Output of systemctl after a boot

Output of systemctl --full after an initial boot
Comment 4 Ian Chapman 2012-10-28 08:12:27 EDT
Created attachment 634511 [details]
Contents of /etc/fstab

Contents of /etc/fstab
Comment 5 Michal Schmidt 2012-10-29 10:52:45 EDT
(In reply to comment #1)
> Created attachment 634508 [details]

Please do not compress bugzilla attachments in the future.

The log is a bit confusing, because it appears that CTRL+ALT+DEL was pressed 47 times within the captured window. Due to this, the output got so long that it already rotated away the boot part and the first shutdown attempt.
I can see that the problem has something to do with device mapper, but if you could capture a new log with a minimal number of CTRL+ALT+DEL presses (or possibly with a bigger value of log_buf_len=...), it would make it easier to analyze.
Comment 6 Ian Chapman 2012-10-30 05:56:33 EDT
It may be lvm2-monitor causing a problem, possibly related to:


[  192.915429] device-mapper: ioctl: unable to remove open device rootvg-root_mimage_1
[  192.917732] device-mapper: ioctl: unable to remove open device rootvg-root_mimage_0
[  192.919992] device-mapper: ioctl: unable to remove open device rootvg-root_mlog
[  192.925921] device-mapper: ioctl: unable to remove open device rootvg-root_mimage_1
[  192.928200] device-mapper: ioctl: unable to remove open device rootvg-root_mimage_0
[  192.930456] device-mapper: ioctl: unable to remove open device rootvg-root_mlog
[  192.938933] device-mapper: ioctl: unable to remove open device rootvg-root_mimage_1
[  192.941179] device-mapper: ioctl: unable to remove open device rootvg-root_mimage_0
[  192.943424] device-mapper: ioctl: unable to remove open device rootvg-root_mlog


Thanks Michal, I'll attach some additional logs shortly, both with & without lvm2-monitor running, using a larger buffer size and without the ctrl-alt-del spamming.
Comment 7 Ian Chapman 2012-10-30 09:01:17 EDT
Created attachment 635564 [details]
Shutdown log - lvm2 monitor enabled

Shutdown log with lvm2 montior enabled
Comment 8 Ian Chapman 2012-10-30 09:16:44 EDT
Created attachment 635573 [details]
Shutdown log lvm2 monitor disabled

Shutdown log with lvm2 monitor disabled
Comment 9 Lennart Poettering 2012-10-30 17:46:32 EDT
Reassigning to LVM as this looks like a device mapper/LVM issue.
Comment 10 Peter Rajnoha 2012-10-31 06:49:27 EDT
(In reply to comment #6)
> [  192.915429] device-mapper: ioctl: unable to remove open device
> rootvg-root_mimage_1
> [  192.917732] device-mapper: ioctl: unable to remove open device
> rootvg-root_mimage_0
> [  192.919992] device-mapper: ioctl: unable to remove open device
> rootvg-root_mlog
> [  192.925921] device-mapper: ioctl: unable to remove open device
> rootvg-root_mimage_1
> [  192.928200] device-mapper: ioctl: unable to remove open device
> rootvg-root_mimage_0
> [  192.930456] device-mapper: ioctl: unable to remove open device
> rootvg-root_mlog
> [  192.938933] device-mapper: ioctl: unable to remove open device
> rootvg-root_mimage_1
> [  192.941179] device-mapper: ioctl: unable to remove open device
> rootvg-root_mimage_0
> [  192.943424] device-mapper: ioctl: unable to remove open device
> rootvg-root_mlog
> 

So this is an LVM mirror device with root fs on it. I assume these messages come from the loop at the very end of systemd shutdown procedure where all the remaining devices are cleaned up. Looking at the error messages which include "mimage" and "mlog" devices only, it seems that these are removed first, not the top-level device (which is "rootvg-root" in this case). That top-level device representing the mirror volume itself holds those mimage devs and the mlog. We always need to deactivate this top-level device first (...if you want to see the device hierarchy, you can use the "lsblk" command that shows it nicely).

Despite those error messages (where the cause is obvious), the delay/hang should not be there. I'll try to have a look what might be the real cause here.
Comment 11 Ian Chapman 2012-10-31 07:30:23 EDT
(In reply to comment #10)

> (...if you want to see the device hierarchy, you can use the "lsblk" command
> that shows it nicely).
> 
> Despite those error messages (where the cause is obvious), the delay/hang
> should not be there. I'll try to have a look what might be the real cause
> here.

I had the shutdown problem, even before the root file system was an LVM mirror. 4 or 5 months ago, I replaced a failing disk and decided to convert most of the volumes into mirrors. 

If you'd like me to attach the output of lsblk, lvs, vgs etc, please let me know.
Comment 12 Ian Chapman 2013-04-12 11:09:59 EDT
Any update?
Comment 13 Fedora End Of Life 2013-07-03 22:43:05 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 '17'.

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 17'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 17 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  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

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.
Comment 14 Fedora End Of Life 2013-08-01 05:14:41 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.

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