Bug 644905 - The post-inst script should call dmeventd -R when possible.
Summary: The post-inst script should call dmeventd -R when possible.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Rajnoha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-20 15:17 UTC by Petr Rockai
Modified: 2012-03-08 13:54 UTC (History)
11 users (show)

Fixed In Version: lvm2-2.02.95-2.fc18
Clone Of:
Environment:
Last Closed: 2012-03-08 13:54:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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...


Note You need to log in before you can comment on or make changes to this bug.