Red Hat Bugzilla – Full Text Bug Listing
|Summary:||lvm-monitor of snapshot hangs at reboot/shutdown|
|Product:||[Fedora] Fedora||Reporter:||Clyde E. Kunkel <clydekunkel7734>|
|Component:||lvm2||Assignee:||Milan Broz <mbroz>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||agk, an0nym, bmarzins, bmr, bugzilla_redhat, dev, djmagee, dwysocha, heinzm, h.reindl, jlaska, johannbg, jonathan, kparal, kupo, lpoetter, lvm-team, maurizio.antillon, mbroz, metherid, mschmidt, msnitzer, notting, philip, plautrba, prajnoha, prockai, pvrabec, skarllot, tflink, vezza, wolfgang.rupprecht, zkabelac|
|Fixed In Version:||lvm2-2.02.84-4.fc15||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-10-20 08:20:09 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Clyde E. Kunkel 2011-03-02 11:23:37 EST
Description of problem: during shutdown/reboot the following msgs appear amongst many msgs: Series of normal shutdown/reboot msgs, then: ... lvm2-monitor.service: control process exited, code=exited status=1 ... lvm[pid]: There are still devices being monitored lvm[pid]: Refusing to exit ... Version-Release number of selected component (if applicable): lvm2-2.02.84-1.fc15.x86_64 systemd-19-1.fc15.x86_64 How reproducible: every boot/reboot Steps to Reproduce: 1. selected reboot or boot 2. 3. Actual results: after the refusing to exit msg, some other unrelated normal msgs appear and then the machine hangs for up to one minute plus. Expected results: normal fast shutdown/reboot Additional info: could this be a systemd issue? only one snapshot of /home LV created using system-config-lvm $ sudo lvscan ACTIVE '/dev/VolGroup00/rawhide' [15.00 GiB] inherit ACTIVE '/dev/VolGroup00/fedora14' [13.67 GiB] inherit ACTIVE '/dev/VolGroup00/fedora13' [11.72 GiB] inherit ACTIVE '/dev/VolGroup00/fedora12' [11.72 GiB] inherit ACTIVE '/dev/VolGroup00/fedora15' [14.65 GiB] inherit ACTIVE '/dev/VolGroup04/fed14btrfs' [11.72 GiB] inherit ACTIVE '/dev/VolGroup03/debian60' [13.97 GiB] inherit ACTIVE Original '/dev/VolGroup01/clydehome' [19.53 GiB] inherit ACTIVE '/dev/VolGroup01/secondhome' [20.00 GiB] inherit ACTIVE Snapshot '/dev/VolGroup01/clydesnap' [20.00 GiB] inherit ACTIVE '/dev/VolGroup02/omega11' [20.00 GiB] inherit ACTIVE '/dev/VolGroup02/centos' [20.00 GiB] inherit ACTIVE '/dev/VolGroup02/suse' [20.00 GiB] inherit ACTIVE '/dev/VolGroup02/fedora13' [20.00 GiB] inherit ACTIVE '/dev/VolGroup02/ubuntu' [15.00 GiB] inherit ACTIVE '/dev/VolGroup02/rhel6' [20.00 GiB] inherit ACTIVE '/dev/VolGroup02/mandriva' [12.00 GiB] inherit ACTIVE '/dev/VolGroup02/downloads' [40.00 GiB] inherit
Comment 1 Milan Broz 2011-03-22 14:41:03 EDT
> lvm[pid]: There are still devices being monitored > lvm[pid]: Refusing to exit It means that some devices were not deactivated, here probably these with snapshot. I guess systemd should deactivate all devices before stopping this service and if it is root volume (with possibly snapshot, which is being monitored) it should hanle this situation specially? (Ignore it?) Reassingning to systemd, but it is possible that something is still missing on lvm side - but then we need discuss how it should work. Monitoring should do two things: - for lvm mirrors it handles device failures etc - for lvm snapshots it monitors free space in snapshot and allows automatic extension on some threshold. So blindly stop monitoring for the active device is not an option. But for system root device is it problem (another one in shutdown mix).
Comment 2 Clyde E. Kunkel 2011-03-22 16:13:17 EDT
Just tried re-enabling lvm2-monitor via systemctl enable lvm2-monitor.service. On reboot, system hung with same msgs. snapshot is of home directory. / is on lv fedora15. Now disabling lvm2-monitor. BTW, works ok on fedora 14 without systemd.
Comment 3 Lennart Poettering 2011-03-31 07:54:54 EDT
I think I explained that at various occasions, but LVM is really broken here. If the monitor needs to run until after all FS are unmounted, then we'd need to unmount /remount read-only first, and kill the monitor after. That would require however that the monitor is not residing on the disk itself, because otherwise the monitor will block unmounting and remounting (the latter in case an upgrade was done and the monitor binary itself or a library it used (like libc) was replaced. Unix filesystems where a file was deleted which is still access cannot be mounted read-only until the access ends). However, the monitor resides on the root fs, hence it is not possible to always cleanly unmount/remount /. Hence, the monitor really should be killed at shutdown like any other process, because otherwise it is impossible to unmount/remount everything cleanly. If the monitor needs to sync meta data to disk after unmount then it should place a tiny binary in /lib/systemd/system-shutdown which is executed at the very end of everything, after unmounting and detaching all devices, right before we call reboot(). That binary should synchronously sync all meta data to disk and exit. systemd will wait for it to terminate. If such a tiny binary is used, then we can be sure that during the unmount/remount step not a single process is referencing any data on any fs anymore and hence we can reliable unmount/remount all file systems.
Comment 4 Zdenek Kabelac 2011-03-31 08:25:44 EDT
I could image a side step - to restart monitor before doing such shutdown - hence it should be possible then to remount filesystem 'ro' - as the updated libs/execs would be loaded from existing inodes ? I don't see a big difference in make a special next small daemon - as it would need all the wisdom from lvm library anyway....
Comment 5 Lennart Poettering 2011-03-31 08:39:27 EDT
Well, that tiny binary could be a shell script that just starts the monitor, waits for it to sync and kills it again then. Would that work?
Comment 6 Clyde E. Kunkel 2011-04-12 10:57:35 EDT
Should this be a blocker for Fedora 15?
Comment 7 James Laska 2011-04-12 11:20:14 EDT
(In reply to comment #6) > Should this be a blocker for Fedora 15? I think this qualifies as a NTH for Fedora 15 Final. We have no existing criteria that cover the use of LVM snapshots.
Comment 8 Tim Flink 2011-04-25 12:07:54 EDT
Discussed at the 2011-04-15 blocker bug review meeting. While this doesn't hit any release criteria, it is a pain and could cause a user to think that their system was broken - accepted as NTH for F15.
Comment 9 Wolfgang Rupprecht 2011-05-27 02:15:51 EDT
I'm also seeing the 5-7 minute hangs on f15 shutdown a few lines after the lvm monitor complains as above. In my case (and perhaps most?) the snapshots are just for making backups. If we are rebooting the snapshots might as well be deleted and the backup restarted from the beginning. I'll just hack that into my /etc/rc.local .
Comment 10 bugzilla_redhat 2011-06-10 09:46:32 EDT
+1 I have a mirrored LVM volume and root on LVM. After upgrading to F15, my shutdown "appeared" to be broken. I'm not sure what the best workaround is for this. I don't see this issue in the Release Notes or CommonBugs. I suggest it needs to have CommonBugs keyword.
Comment 11 Charlweed Hymerfan 2011-06-11 20:03:05 EDT
Took me several hours to find this bug report, as it's not in the release notes or anything, and I did not know it was LVM + systemd related. This is a severe bug for us, as effectively, systems can neither be shutdown nor booted. Even as I've researched this issue for the last hour, my system has not shut down. Now I don't know what I must do to get it to boot past the LVM mounts. Can someone please post a clear workaround so that a system with LVM can start and stop cleanly? Thanks!
Comment 12 Clyde E. Kunkel 2011-06-12 10:58:15 EDT
The system should eventually shutdown and then can reboot. The only workaround I know of until this is fixed is to: 1) reboot; 2) systemctl disable lvm2-monitor.service; 3) systemctl stop lvm2.service. Now, unfortunately, wait again a long time. But, with the service disabled, it will not be started on subsequent boots. Downside is no monitoring of snapshots and lvs. It looks like there a peeing contest about who or what is the culprit.
Comment 13 Clyde E. Kunkel 2011-06-23 11:01:48 EDT
This problem is still present in rawhide. It really needs to be fixed. Thanks.
Comment 14 Clyde E. Kunkel 2011-06-23 11:26:30 EDT
$ time sudo systemctl stop lvm2-monitor.service real 5m0.167s user 0m0.003s sys 0m0.034s seems excessive for a single snapshot
Comment 15 an0nym 2011-06-27 12:08:53 EDT
*** Bug 716737 has been marked as a duplicate of this bug. ***
Comment 16 an0nym 2011-06-27 12:27:46 EDT
I am expiriencing the same problem with long soft reboots and power offs. I have no snapshots, but have mirroring and striping using lvm internal capabilities.
Comment 17 Charlweed Hymerfan 2011-06-29 19:49:47 EDT
20 minutes to boot? More than 45 minutes to shutdown? This should be a HIGH severity bug. Who has 20 minutes to get their laptop to boot? Who has over 45 minutes of reserve power on their server's UPS? 45 min to power off means LOSS OF DATA, which is the criteria for a HIGH severity bug. Nobody can sell anything that takes 20 min of doing nothing before it can start, and I cannot imagine anyone who would want it. The fact that this bug leaves a system in a completely unusable state, for extended periods of time, should make this a HIGH priority bug.
Comment 18 an0nym 2011-06-30 07:52:52 EDT
I agree with the previous poster. I don't have a server or a UPS, but waiting 5 minutes to reboot annoys and sometimes I just do hard reset risking my data. This is really bad and need to be fixed asap.
Comment 19 Peter Rajnoha 2011-07-12 04:38:46 EDT
We'll provide native systemd unit files soon that will disable monitoring at the very possible end. This should also prevent this bug that happens with the legacy SysV init scripts when run by systemd. In review.
Comment 20 Peter Rajnoha 2011-07-18 09:22:46 EDT
We have a rawhide package now (bug #714698). If we don't hit any problem, we'll port the patch for F15 as well.
Comment 21 Michal Schmidt 2011-07-18 10:14:49 EDT
Peter, if you are going to fix this bug by migrating to a native systemd service, please note that in general it is not acceptable: Packages are strictly forbidden from migrating to systemd within updates to a Fedora release. The migration is only allowed between Fedora releases. -- http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript It would be nice to have this bug fixed in F15 though, and if no other fix is possible, you may be able to get an exception from FESCo in order to ignore this guideline.
Comment 22 Peter Rajnoha 2011-07-18 10:35:41 EDT
The other solution would be to keep the old SysV init script and call force-stop instead of stop (alternatively, we could patch it so the "stop" functionality would be equal to "force-stop"). An important thing to mention here is that lvm2-monitor will stop too early this way. But this will get resolved eventually with F16 and late shutdown ramfs that is in plan there.
Comment 23 Clyde E. Kunkel 2011-07-19 11:42:05 EDT
lvm2-2.02.86-2.fc16.x86_64 fixes this problem in rawhide. However, since it still exists in F15, will defer closing this bz.
Comment 24 Doug Magee 2011-08-03 11:57:20 EDT
lvm2 >= 2.02.86-2 fixes the problem for me, however, on my two real machines, i can no longer use lv* commands to create/remove snapshots or mirrors (or possibly anything at all). It works fine in a VM with a fresh PV set up by the installer, but in my two 'real world' examples, using PVs/VGs that were originally created in F12, the toolstack from rawhide is nonfunctional. Reverting to F15 lvm2 packages works fine. Was there a change (for example, in the metadata format) that may have occurred since F12 that would prevent me from using F16+ lvm tools?
Comment 25 Alasdair Kergon 2011-08-03 12:13:21 EDT
Nothing should have broken format-wise. Run the simplest failing command you can find with -vvvv and see what the errors really are? (Probably best on a different bugzilla to avoid making this one drift too far off track.)
Comment 26 Doug Magee 2011-08-03 13:02:59 EDT
(In reply to comment #25) > Nothing should have broken format-wise. Run the simplest failing command you > can find with -vvvv and see what the errors really are? (Probably best on a > different bugzilla to avoid making this one drift too far off track.) Posted as bug 727925
Comment 27 Peter Rajnoha 2011-08-08 09:33:49 EDT
Well, I've just noticed that the $runlevel variable is not set at all by systemd during shutdown/reboot. This variable is checked and to differentiate between a situation in which a proper shutdown/reboot is called and user calling the 'stop' script directly. I think that variable should be set if systemd runs the scripts in the SysV compatibility mode. So I hope this will be fixed in systemd directly (filed as bug #728955). If that's going to be fixed in systemd, I'll close this bug then.
Comment 28 Peter Rajnoha 2011-09-08 06:35:42 EDT
*** Bug 736620 has been marked as a duplicate of this bug. ***
Comment 29 Alasdair Kergon 2011-09-08 08:03:00 EDT
To summarise: The root cause of this turned out to be the withdrawal of the $runlevel variable in F15. This is not going to get reinstated. (bug #728955) The best fix in our opinion was to switch from a SysV initscript to the systemd equivalent immediately. However, this option had to be ruled out because Fedora strictly forbids it: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migrating_to_a_systemd_unit_file_from_a_SysV_initscript The problem is resolved in F16 as far as we know, so people wanting to deal with it should choose a 'least bad' workaround until they upgrade. If you decide your 'least bad' option is to break the rules and switch to systemd early, we will attach a package that uses systemd to this bugzilla for you shortly.
Comment 30 Harald Reindl 2011-09-08 08:16:23 EDT
please make a update for F15 this packaging-rules are useless if broken components are released as GA and any rule forbid to fix this - in this case the conversion had to be done BEFORE GA or has to be fixed in the lifetime-cycle
Comment 31 Michal Schmidt 2011-09-08 08:18:56 EDT
(In reply to comment #29) > The best fix in our opinion was to switch from a SysV initscript to the > systemd equivalent immediately. However, this option had to be ruled out > because Fedora strictly forbids it I recommend filing a request for an exception from the strict rule with FESCo: https://fedorahosted.org/fesco/ Fixing this bug should be a sufficient rationale for getting the exception. > If you decide your 'least bad' option is to break the rules and switch to > systemd early, we will attach a package that uses systemd to this bugzilla for > you shortly. Yes, please attach the package, so that the reporters can verify it works as expected.
Comment 32 Alasdair Kergon 2011-09-08 08:52:00 EDT
The policy is quite clear - strictly forbidden. That doesn't allow for exceptions, surely? You'd need to lobby to get that bit of the policy changed first.
Comment 33 Alasdair Kergon 2011-09-08 08:57:04 EDT
Anyway, let's get a possible package sorted out first and see if breaking this rule causes any technical problems for anyone or not.
Comment 34 Clyde E. Kunkel 2011-09-08 10:24:18 EDT
I would be happy to test a potential fix for this F15 problem while the bureaucrats resolve the policy issues.
Comment 35 Michal Schmidt 2011-09-08 10:29:52 EDT
(In reply to comment #32) > The policy is quite clear - strictly forbidden. That doesn't allow for > exceptions, surely? Surely FESCo has the authority to grant an exception to any rule. Actually, there is a generic exception clause at the beginning of the Guidelines, http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Guidelines: If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee. So it seems the correct body to ask is FPC, not FESCo. https://fedorahosted.org/fpc/
Comment 36 Peter Rajnoha 2011-09-08 11:10:15 EDT
You can find unofficial builds with systemd support backport here: x86_64: http://koji.fedoraproject.org/koji/taskinfo?taskID=3335365 i686: http://koji.fedoraproject.org/koji/taskinfo?taskID=3335366
Comment 37 Peter Rajnoha 2011-09-08 11:12:27 EDT
Created attachment 522142 [details] F15 lvm2 build with systemd support Attaching x86_64 build here as well.
Comment 38 Peter Rajnoha 2011-09-08 11:14:18 EDT
Created attachment 522143 [details] F15 lvm2 build with systemd support (i686) Attaching i686 build here as well.
Comment 39 Peter Rajnoha 2011-09-08 11:18:49 EDT
Please, try these unofficial packages and if you hit any problems while doing an update, report them here in this bug report. Thanks.
Comment 40 Peter Rajnoha 2011-09-08 11:25:12 EDT
Created attachment 522145 [details] F15 lvm2 with systemd support - src rpm
Comment 41 Clyde E. Kunkel 2011-09-08 13:14:49 EDT
$ rpm -qa | grep lvm2 lvm2-2.02.84-4.fc15.x86_64 lvm2-libs-2.02.84-4.fc15.x86_64 lvm2-sysvinit-2.02.84-4.fc15.x86_64 $ systemctl status lvm2-monitor.service lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling Loaded: loaded (/lib/systemd/system/lvm2-monitor.service) Active: active (exited) since Thu, 08 Sep 2011 13:07:19 -0400; 6min ago Process: 1250 ExecStart=/sbin/lvm vgchange --monitor y (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/lvm2-monitor.service Working here now on F15. Boot/reboot as fast as before. Suggest this bz be left open in case an official release to F15 is denied so anyone running into this will find more easily. Even tho F15 will be EOL first half of next year anyway, there will be folks who continue to use it and may run into this.
Comment 42 Peter Rajnoha 2011-09-09 02:35:40 EDT
(In reply to comment #41) > $ rpm -qa | grep lvm2 > lvm2-2.02.84-4.fc15.x86_64 > lvm2-libs-2.02.84-4.fc15.x86_64 > lvm2-sysvinit-2.02.84-4.fc15.x86_64 Just a note: You don't need to install the sysvinit subpackage. This one is just for the ones who still want to use the old init script for some reason so they can find it here. Anyway, if you install lvm2 package together with lvm2-sysvinit subpackage, the systemd unit installed with lvm2 will prevail and it will be used primarily instead of SysV init script (systemd takes care of this).
Comment 43 Milan Broz 2011-09-20 07:37:34 EDT
*** Bug 739867 has been marked as a duplicate of this bug. ***
Comment 44 Milan Broz 2011-09-20 07:39:01 EDT
Peter, please can we build workaround package for F15? It is impossible to switch to systemd in F15 and this problem hits many users.
Comment 45 Harald Reindl 2011-09-20 07:44:46 EDT
and that is the reason for my repeated question why damned was the users forced to use systemd with F15 before the distribution is ready and why in the world it is forbidden to fix such things in the life-cycle of F15? i have rebuilt the F16 package for F15 and it is runnign well, solves the problem and only a idiotic policy prevents to fix this for all - since Fedora defaults to LVM this is a core-package and must not have been pushed without converting BEFORE the release such things have to be a blocker by making large chnages like introduce systemd
Comment 46 Milan Broz 2011-09-20 07:55:18 EDT
(In reply to comment #45) > is ready and why in the world it is forbidden to fix such things in the > life-cycle of F15? I'll create Fesco ticket if needed. But in this case we have simple not intrusive workaround, so I would better see to use that for now.
Comment 47 Peter Rajnoha 2011-09-20 08:21:13 EDT
A very very simple update would be (however, if people will call "lvm2-monitor stop" directly, it won't deny the action as is now in F15 - it'll just do it. Normally, you would need to use "lvm2-monitor force-stop" instead): scripts/lvm2_monitoring_init_red_hat.in | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/scripts/lvm2_monitoring_init_red_hat.in b/scripts/lvm2_monitoring_init_red_hat.in index 0988511..087f36c 100644 --- a/scripts/lvm2_monitoring_init_red_hat.in +++ b/scripts/lvm2_monitoring_init_red_hat.in @@ -92,8 +92,7 @@ case "$1" in ;; stop) - test "$runlevel" = "0" && WARN=0 - test "$runlevel" = "6" && WARN=0 + WARN=0 stop rtrn=$? [ $rtrn = 0 ] && rm -f $LOCK_FILE
Comment 48 Peter Rajnoha 2011-09-20 08:25:19 EDT
The stop mechanism was allowed only during restart and shutdown, but we can't test it anymore since systemd does not provide the runlevel info in the $runlevel variable. Also the "runlevel" command is not deterministic, bug #728955 ... If we're going to do an update, I'm voting for this simple patch instead.
Comment 49 Fedora Update System 2011-09-20 12:17:04 EDT
lvm2-2.02.84-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/lvm2-2.02.84-4.fc15
Comment 50 Milan Broz 2011-09-20 12:18:21 EDT
I submitted update to F15 testing with workaround mentioned in comment #47, I hope it helps for now.
Comment 51 Clyde E. Kunkel 2011-09-20 12:32:13 EDT
(In reply to comment #49) > lvm2-2.02.84-4.fc15 has been submitted as an update for Fedora 15. > https://admin.fedoraproject.org/updates/lvm2-2.02.84-4.fc15 Will this cause a problem if we installed the fix in comment #37? TIA
Comment 52 Milan Broz 2011-09-20 14:27:00 EDT
I would say - if you installed fix from comment #37, stay with it. (It has the same n-v-r so update should not automatically reinstall it. But reinstall should just switch initscripts back to sysv mode, it should not cause big problems (but not tested).
Comment 53 Fedora Update System 2011-09-20 20:04:39 EDT
Package lvm2-2.02.84-4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lvm2-2.02.84-4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/lvm2-2.02.84-4.fc15 then log in and leave karma (feedback).
Comment 54 Alasdair Kergon 2011-09-20 21:19:40 EDT
How about adding to the inline comment something like: # This means that in Fedora 15, as a side-effect of facilitating a clean # system shutdown, the script will NOT warn you of the problems you may # cause if you stop this service while the system still requires it to be # running.
Comment 55 Fedora Update System 2011-09-24 23:44:12 EDT
lvm2-2.02.84-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Comment 56 Fabrício Godoy 2011-10-12 11:56:19 EDT
Don't works for me. # lvscan ACTIVE '/dev/VG_Data/LV_Data' [648,00 GiB] inherit ACTIVE '/dev/VG_System/LV_Root' [50,00 GiB] inherit ACTIVE '/dev/VG_System/LV_Home' [30,00 GiB] inherit ACTIVE '/dev/VG_System/LV_Swap' [3,00 GiB] inherit # lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert LV_Data VG_Data -wi-ao 648,00g LV_Home VG_System mwi-ao 30,00g LV_Home_mlog 100,00 LV_Root VG_System -wi-ao 50,00g LV_Swap VG_System -wi-ao 3,00g
Comment 57 Peter Rajnoha 2011-10-13 04:37:31 EDT
(In reply to comment #56) > Don't works for me. Please, check the content of /etc/rc.d/init.d and see if these lines are commented out: # # Because systemd doesn't support setting of $runlevel # https://bugzilla.redhat.com/show_bug.cgi?id=728955 # we have to use workaround here. # # test "$runlevel" = "0" && WARN=0 # test "$runlevel" = "6" && WARN=0
Comment 58 Fabrício Godoy 2011-10-16 20:47:44 EDT
(In reply to comment #57) > (In reply to comment #56) > > Don't works for me. > > Please, check the content of /etc/rc.d/init.d and see if these lines are > commented out: > > # > # Because systemd doesn't support setting of $runlevel > # https://bugzilla.redhat.com/show_bug.cgi?id=728955 > # we have to use workaround here. > # > # test "$runlevel" = "0" && WARN=0 > # test "$runlevel" = "6" && WARN=0 Yes, it is.
Comment 59 Johan Swensson 2011-10-19 07:15:46 EDT
(In reply to comment #58) > (In reply to comment #57) > > (In reply to comment #56) > > > Don't works for me. > > > > Please, check the content of /etc/rc.d/init.d and see if these lines are > > commented out: > > > > # > > # Because systemd doesn't support setting of $runlevel > > # https://bugzilla.redhat.com/show_bug.cgi?id=728955 > > # we have to use workaround here. > > # > > # test "$runlevel" = "0" && WARN=0 > > # test "$runlevel" = "6" && WARN=0 > > Yes, it is. Having the same problem. The lines are commented out here as well. lvm2-2.02.84-4.fc15.x86_64 lvm2-libs-2.02.84-4.fc15.x86_64
Comment 60 Peter Rajnoha 2011-10-20 05:17:46 EDT
(In reply to comment #59) > Having the same problem. The lines are commented out here as well. Does it hang if you call "systemctl stop lvm2-monitor.service" on command line directly?
Comment 61 Kamil Páral 2011-10-20 05:48:22 EDT
# systemctl status lvm2-monitor.service lvm2-monitor.service - LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling Loaded: loaded (/etc/rc.d/init.d/lvm2-monitor) Active: active (running) since Thu, 20 Oct 2011 11:36:36 +0200; 2s ago Process: 12706 ExecStop=/etc/rc.d/init.d/lvm2-monitor stop (code=exited, status=0/SUCCESS) Process: 12797 ExecStart=/etc/rc.d/init.d/lvm2-monitor start (code=exited, status=0/SUCCESS) Main PID: 12805 (dmeventd) CGroup: name=systemd:/system/lvm2-monitor.service └ 12805 /sbin/dmeventd # time systemctl stop lvm2-monitor.service real 5m0.525s user 0m0.000s sys 0m0.004s # systemctl status lvm2-monitor.service lvm2-monitor.service - LSB: Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling Loaded: loaded (/etc/rc.d/init.d/lvm2-monitor) Active: failed since Thu, 20 Oct 2011 11:41:44 +0200; 6min ago Process: 12812 ExecStop=/etc/rc.d/init.d/lvm2-monitor stop (code=exited, status=0/SUCCESS) Process: 12797 ExecStart=/etc/rc.d/init.d/lvm2-monitor start (code=exited, status=0/SUCCESS) Main PID: 12805 (code=killed, signal=KILL) CGroup: name=systemd:/system/lvm2-monitor.service
Comment 62 Kamil Páral 2011-10-20 05:52:53 EDT
I have to say it sometimes shutdowns fine and sometimes I have to use SysRq to turn off the computer at all (in reasonable time, I never tried waiting 5 minutes). So it's not 100% reproducible. But stopping the service manually took very long in 2 out of 2 attempts, so the reproducibility should be high enough.
Comment 63 Peter Rajnoha 2011-10-20 08:20:09 EDT
(In reply to comment #62) > I have to say it sometimes shutdowns fine and sometimes I have to use SysRq to > turn off the computer at all (in reasonable time, I never tried waiting 5 > minutes). So it's not 100% reproducible. But stopping the service manually took > very long in 2 out of 2 attempts, so the reproducibility should be high enough. I've looked at this with Kamil on his machine and it seems the script is executed properly. Debug log of the lvm2-monitor sysv script execution - "systemctl stop lvm2-monitor.service": + echo -n 'Stopping monitoring for VG encvg: ' Stopping monitoring for VG encvg: + shift + /sbin/vgchange --monitor n encvg 3 logical volume(s) in volume group "encvg" unmonitored + success 'Stopping monitoring for VG encvg:' ... + echo -n ' OK ' ... + return 0 ... + echo -n 'Stopping monitoring for VG vg: ' Stopping monitoring for VG vg: + shift + /sbin/vgchange --monitor n vg 12 logical volume(s) in volume group "vg" unmonitored + success 'Stopping monitoring for VG vg:' ... + echo -n ' OK ' ... + return 0 So it seems the hang occurs somewhere in systemd/systemctl. I'll open a separate bug for systemd.
Comment 64 Peter Rajnoha 2011-10-20 08:28:51 EDT
(In reply to comment #63) > So it seems the hang occurs somewhere in systemd/systemctl. I'll open a > separate bug for systemd. bug #747582
Comment 65 Fabrício Godoy 2011-10-22 14:03:24 EDT
(In reply to comment #60) > (In reply to comment #59) > > Having the same problem. The lines are commented out here as well. > > Does it hang if you call "systemctl stop lvm2-monitor.service" on command line > directly? Yes, takes forever. I just Ctrl+C stop. If I call force-stop, it just stops well. I don't know if it is related, look piece of my mount list: . . . /dev/mapper/VG_Data-LV_Data on /Data type ext3 (rw,nosuid,relatime,seclabel,errors=continue,barrier=0,data=ordered) /dev/mapper/VG_System-LV_Home on /home type ext3 (rw,relatime,seclabel,errors=continue,user_xattr,barrier=0,data=ordered) /dev/mapper/VG_System-LV_Root on /tmp type ext3 (rw,relatime,seclabel,errors=continue,barrier=0,data=ordered) /dev/mapper/VG_System-LV_Root on /var/tmp type ext3 (rw,relatime,seclabel,errors=continue,barrier=0,data=ordered) /dev/mapper/VG_System-LV_Home on /home type ext3 (rw,relatime,seclabel,errors=continue,user_xattr,barrier=0,data=ordered) . . . It's don't looks right.