-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Force systemd to stop lvm2-lvmetad.service before shutting down. #17
Comments
It seems that we encounter the same problem. |
Thanks for reporting the issue, it should be fixed now with: (master tree) (stable-2.02 tree) |
Thanks a lot, you're awesome! |
I think something went wrong with the backport in 0a726a7e268b31856615491809af73bda5d4d6f9.
Is it actually correct to do stuff like this? Doesn't look like it, cherry-picking this commit breaks boot in Arch (FS#62302). |
I'm using manjaro and after the last update of of lvm2 ( 2.02.184-2) which include the fix commit the "long shutdown" issue solved but now from journalctl I get: manjaro systemd[1]: boot-efi.mount: Job lvm2-lvmetad.socket/start deleted to break ordering cycle starting with boot-efi.mount/start
manjaro systemd[1]: boot-efi.mount: Job lvm2-monitor.service/start deleted to break ordering cycle starting with boot-efi.mount/start |
My mistake, sorry for that. I expected the sockets.target to be reached sooner during boot, but it's even after sysinit.target (https://www.freedesktop.org/software/systemd/man/bootup.html). So yes, we still need the DefaultDependencies=no there. (master tree) (stable-2.02 tree) |
It's fixed for me with lvm2 2.02.184-4 in arch. |
…hutdown ordering We already used Conflicts=shutdown target to stop LVM2 services on shutdown. But we still missed the ordering - the shutdown.target should be reached only after all the services are really stopped. Reported here: lvmteam/lvm2#17
…hutdown ordering We already used Conflicts=shutdown target to stop LVM2 services on shutdown. But we still missed the ordering - the shutdown.target should be reached only after all the services are really stopped. Reported here: #17
I noticed that systemd sometimes reaches shutdown.target before lvm2-lvmetad.service has been stopped. Since lvm2-lvmetad.service (a.k.a. lvm2_lvmetad_systemd_red_hat.service.in in the "scripts" folder) has
but no
in it, this problem can easily occur if the service doesn't react to SIGTERM fast enough.
In case it does happen, with kernels 5.0.0 and up the shutdown/reboot procedure can be interrupted.
If we would add
to the service file we could avoid the issue. I heared a some Arch Linux users are suffering from this occasional problem, as described in this bug report.
This issue at systemd is also related to the problem, as @patrakov describes.
Thanks for your efforts in advance.
The text was updated successfully, but these errors were encountered: