[Bug 914415] New: lvm2-lvmetad.service will be running unexpected after package updated
http://bugzilla.suse.com/show_bug.cgi?id=914415 Bug ID: 914415 Summary: lvm2-lvmetad.service will be running unexpected after package updated Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: lwang@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 620616 --> http://bugzilla.suse.com/attachment.cgi?id=620616&action=edit jounalctl when updating Before updating, lvm2-lvmetad.service is inactive, which is what we expected. # systemctl status lvm2-lvmetad lvm2-lvmetad.service - LVM2 metadata daemon Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled) Active: inactive (dead) Docs: man:lvmetad(8) The related setting is 1. # grep use_lvmetad /etc/lvm/lvm.conf use_lvmetad = 0 2. # grep lvm2 /usr/lib/systemd/system-preset/90-default-openSUSE.preset enable lvm2-lvmetad.socket After lvm2 is updated to the lates version on opensuse:factory, lvme2-lvmetad.service will be running. # rpm -U ./lvm2-2.02.114-52.1.x86_64.rpm --nodeps # systemctl status lvm2-lvmetad lvm2-lvmetad.service - LVM2 metadata daemon Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled) Active: active (running) since Fri 2015-01-23 13:02:59 CST; 43s ago Docs: man:lvmetad(8) Main PID: 21053 (lvmetad) CGroup: /system.slice/lvm2-lvmetad.service └─21053 /sbin/lvmetad -f #reboot lvm2-lvmetad.service is inactive again as expected. My question is why lvm2-lvmetad.service is running after updated. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
Liuhua Wang
http://bugzilla.suse.com/show_bug.cgi?id=914415
Martin Pluskal
http://bugzilla.suse.com/show_bug.cgi?id=914415
Chenzi Cao
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #1 from Liuhua Wang
http://bugzilla.suse.com/show_bug.cgi?id=914415
Liuhua Wang
http://bugzilla.suse.com/show_bug.cgi?id=914415
Liuhua Wang
http://bugzilla.suse.com/show_bug.cgi?id=914415
Lidong Zhong
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #2 from Martin Pluskal
Here is the services in lvm2.spec: %pre %service_add_pre lvm2-lvmetad.socket lvm2-lvmetad.service
%post /sbin/ldconfig %{?regenerate_initrd_post} %service_add_post lvm2-lvmetad.socket lvm2-lvmetad.service
%posttrans %{?regenerate_initrd_posttrans}
%preun %service_del_preun lvm2-lvmetad.socket lvm2-lvmetad.service
%postun /sbin/ldconfig %service_del_postun lvm2-lvmetad.socket lvm2-lvmetad.service
I think the reason is because socket/service restarted by %service_del_postun. It seems that while issuing "systemctl try-restart lvm2-lvmetad.service" does not start stopped service: # systemctl try-restart lvm2-lvmetad.service # systemctl status lvm2-lvmetad.service lvm2-lvmetad.service - LVM2 metadata daemon Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled) Active: inactive (dead) since Fri 2015-01-23 09:42:15 CET; 8s ago Docs: man:lvmetad(8) Process: 1746 ExecStart=/sbin/lvmetad -f (code=exited, status=0/SUCCESS) Main PID: 1746 (code=exited, status=0/SUCCESS)
issuing "systemctl try-restart lvm2-lvmetad.service lvm2-lvmetad.socket" or "systemctl try-restart lvm2-lvmetad.socket" does: # systemctl try-restart lvm2-lvmetad.service lvm2-lvmetad.socket # systemctl status lvm2-lvmetad.service lvm2-lvmetad.service - LVM2 metadata daemon Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled) Active: active (running) since Fri 2015-01-23 09:43:26 CET; 5s ago Docs: man:lvmetad(8) Main PID: 1773 (lvmetad) CGroup: /system.slice/lvm2-lvmetad.service └─1773 /sbin/lvmetad -f So as long as lvm2-lvmetad.socket is enabled, lvm2-lvmetad.service will be started on update. Usage of %postun macro itself is correct, however if lvm2-lvmetad.socket should be enabled in presets is different question. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
Martin Pluskal
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #4 from Lidong Zhong
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #5 from Martin Pluskal
What's the current definition of the following four macros in OBS:
%service_add_pre %service_add_post %service_del_preun %service_del_postun They are defined in package systemd-rpm-macros
If it's the same as in SLES11-SP3, There are no %service* macros in SLES11-SP3 as it does not have systemd.
I hope that I don't need to remind you that %service_* macros used for a reason, solving one issue by blindly removing them will likely cause different issues. What seems to be reason for observed behavior is described in comment#3 , lets wait for some output from systemd maintainers. One possible solution that comes to my mind would be to remove .socket from %service_* macros, other would be inspired by X11:XOrg/xdm/xdm.spec - adding "export DISABLE_RESTART_ON_UPDATE=yes" to %postun section. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #6 from Liuhua Wang
I hope that I don't need to remind you that %service_* macros used for a reason, solving one issue by blindly removing them will likely cause different issues. What seems to be reason for observed behavior is described in comment#3 , lets wait for some output from systemd maintainers.
One possible solution that comes to my mind would be to remove .socket from %service_* macros, other would be inspired by X11:XOrg/xdm/xdm.spec - adding "export DISABLE_RESTART_ON_UPDATE=yes" to %postun section.
Yes, if not add to the 4 sections, the socket will not be active. @Lidong, you can see another bug about this: bnc#908791 - lvm2-lvmetad.socket is enabled in sles-preset but is disable in systemctl status -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #7 from Lidong Zhong
If it's the same as in SLES11-SP3, There are no %service* macros in SLES11-SP3 as it does not have systemd.
Sorry, I mean opensuse-12.3 here(opened a wrong shell tab)
I hope that I don't need to remind you that %service_* macros used for a reason, solving one issue by blindly removing them will likely cause different issues. What seems to be reason for observed behavior is described in comment#3 , lets wait for some output from systemd maintainers.
yeah..
One possible solution that comes to my mind would be to remove .socket from %service_* macros, other would be inspired by X11:XOrg/xdm/xdm.spec - adding "export DISABLE_RESTART_ON_UPDATE=yes" to %postun section.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
Chenzi Cao
http://bugzilla.suse.com/show_bug.cgi?id=914415
Dr. Werner Fink
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #10 from Dr. Werner Fink
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #15 from Dr. Werner Fink
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #16 from Martin Pluskal
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #18 from Dr. Werner Fink
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #19 from Dr. Werner Fink
From man:systemctl(1)
enable NAME... [...] Enabling units should not be confused with starting (activating) units, as done by the start command. Enabling and starting units is orthogonal: units may be enabled without being started and started without being enabled. Enabling simply hooks the unit into various suggested places (for example, so that the unit is automatically started on boot or when a particular kind of hardware is plugged in). Starting actually spawns the daemon process (in case of service units), or binds the socket (in case of socket units), and so on. that is if an *traffic* event occurs on a socket then it starts the service. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #20 from Liuhua Wang
(In reply to Martin Pluskal from comment #16)
IMHO the `systemctl try-restart' on a socket isn't that what should be done. Therefore a
Also=lvm2-lvmetad.socket
in the `[Install]' section of the "lvm2-lvmetad.service" should be sufficient to be ablle to remove"lvm2-lvmetad.service" from the %service_add_* macro lines in the spec file.
Thank you for providing that. As my test now these two ways can avoid service from starting after updating package: 1. remove .socket from %service_delete_* macro in %preun and %postun. But I don't think it is good that update a package without socket unit being restarted. 2. add ALSO option to Install section as Werner suggested and remove But seems that it only works in case that the old package as well including an ALSO option. The service will be running if only the new package including ALSO option but the old package not including an ALSO option. Is it expected? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=914415
Dr. Werner Fink
http://bugzilla.suse.com/show_bug.cgi?id=914415
--- Comment #22 from Liuhua Wang
http://bugzilla.suse.com/show_bug.cgi?id=914415
Liuhua Wang
participants (1)
-
bugzilla_noreply@novell.com