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:
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
Created attachment 634509 [details] Contents of /etc/default/grub Contents of /etc/default/grub showing the boot up kernel parameters
Created attachment 634510 [details] Output of systemctl after a boot Output of systemctl --full after an initial boot
Created attachment 634511 [details] Contents of /etc/fstab Contents of /etc/fstab
(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.
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.
Created attachment 635564 [details] Shutdown log - lvm2 monitor enabled Shutdown log with lvm2 montior enabled
Created attachment 635573 [details] Shutdown log lvm2 monitor disabled Shutdown log with lvm2 monitor disabled
Reassigning to LVM as this looks like a device mapper/LVM issue.
(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.
(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.
Any update?
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.
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.