Bug 644905

Summary:	The post-inst script should call dmeventd -R when possible.
Product:	[Fedora] Fedora	Reporter:	Petr Rockai <prockai>
Component:	lvm2	Assignee:	Peter Rajnoha <prajnoha>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	agk, bmarzins, bmr, dwysocha, heinzm, jonathan, lvm-team, mbroz, msnitzer, prajnoha, prockai
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	lvm2-2.02.95-2.fc18	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-08 13:54:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Petr Rockai 2010-10-20 15:17:30 UTC

Now that we have dmeventd -R (for restart) upstream, it should be possible to implement a restart policy for dmeventd in the RPM's post-inst. Care needs to be taken about older versions, since dmeventd -R only works if the *running* dmevend supports the option as well. Killing old dmeventd versions unconditionally and restarting monitoring may be an option, although it's not very nice either.

Comment 1 Peter Rajnoha 2011-10-31 13:37:39 UTC

...as for the rawhide, we have systemd now, so we should be fine with "ExecReload=/sbin/dmeventd -R" in dm-event.service systemd unit.

If there's a new dmeventd running, everything's fine.

If there's still the old dmeventd running (that does not support the -R switch), the "systemctl reload dm-event.service" fails with a warning that it was not possible to execute the reload and it keeps the original dmeventd running which is a correct behaviour.

If called from within an rpm scriptlet (systemctl reload dm-event.service) on package update, we *should not try to kill* the daemon ourselves, otherwise we lose any existing registrations (we would need to call the unmonitor function and then start monitoring again directly for *all* registrations and that's not just the lvm2 case, but it could be used by other subsystems as well). Also, systemd would lose track of the daemon. A user should probably be advised to reboot his machine instead and start up a new dmeventd this way in this particular scenario. This would happen only once when the transition from old to new dmeventd (supporting the -R switch) is done so I don't think this poses a huge problem.

As for the old SysV init system, the logic would be the same.

Comment 2 Peter Rajnoha 2012-03-08 13:54:55 UTC

Finally included in the spec file and built - lvm2-2.02.95-2.fc18! It should have been done long time ago...