This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 644905 - The post-inst script should call dmeventd -R when possible.
The post-inst script should call dmeventd -R when possible.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-20 11:17 EDT by Petr Rockai
Modified: 2012-03-08 08:54 EST (History)
11 users (show)

See Also:
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 08:54:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Petr Rockai 2010-10-20 11:17:30 EDT
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 09:37:39 EDT
...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 08:54:55 EST
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.