Red Hat Bugzilla – Bug 454618
dmevent needs to be restarted during update
Last modified: 2013-02-28 23:06:51 EST
+++ This bug was initially created as a clone of Bug #454349 +++
-- Additional comment from email@example.com on 2008-07-08 05:06 EST --
There is a slight problem with dmeventd restart, since we have to re-register
all the monitored volumes and I don't think there currently is a way to do so
reliably. But we likely want to fix that for 5.3.
-- Additional comment from firstname.lastname@example.org on 2008-07-08 15:33 EST --
Current proposed fix (it is a little ugly, beut should work):
1) Make the "to be monitored" a persistent logical volume property.
2) This can be non-intrusively (in a backward-compatible manner) done by adding
an inverted flag to metadata (say NOMONITORING): if the flag is cleared, it
means that the device will be (if possible) monitored (which is the default)
and when it is set, the device is excluded from monitoring.
3) Add a vgchange (sub-)command to register all applicable LVs for
monitoring -- this can then be used for starting dmeventd after upgrades.
We do 2) to avoid having to flag existing devices upon upgrade, as Milan
pointed out, a possibly dangerous operation.
I have thought about this a bit more, and I guess it will be easier to solve this differently, namely implement dmeventd --restart, which:
1) connect as a client to the existing dmeventd
2) issue a "get status" command (needs to be implemented, but not hard)
3) kill the old dmeventd
4) daemonize &c.
5) set up monitoring based on the get status output from step 2
To make things easy, I would just make the get status command give back a list of dmeventd fifo commands, separated by semicolons (which shouldn't appear in the messages otherwise). So if you have two threads, you get
0:0 /path/to/dso.so /path/to/device <EVENTMASK> <TIMEOUT>; 0:1 /path/to/another/dso.so /path/to/device <EVENTMASK> <TIMEOUT>;
The step 5 can then just consist of replaying these commands, using existing code for that (_parse_message/_register_for_event). The get status command can extract the data from the thread registry without too much trouble.
I'll have a go at an implementation tomorrow.
The patch for this is here: https://www.redhat.com/archives/lvm-devel/2010-October/msg00017.html -- there has been some review (and amendments) already, but not acked yet.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of
Red Hat Enterprise Linux. The error has been fixed and this
request has been re-proposed for the current release.
The dmeventd -R option is available since 2.02.77, I believe. I don't know about the status of the relevant RPM scriptlets, Peter will know more, but I think there is a separate bug for those.
(just notes from irc)
- missing documentation (man page)
- restart only if daemon running (should not fail and start it if not running and -R specified?)
- please specify what should be added into rpm and add it to Fedora
we should probably just run:
%post -n device-mapper-event
and ignore output (starting or killing -9 daemon from update is not good idea, better keep old running as in old version to next reboot)
Moving this to RHEL5.8 / assigned, please apply this to rpm Fedora first.
The man page is now updated, and the current CVS version of -R will proceed to start the daemon if it is currently not running. I concede about the scriptlet, *although* there is one caveat: currently, if dmeventd is not running, it will take a while for dmeventd -R to start up, because we have a long communication timeout. It is not clear whether this is easy to fix -- the current code does not distinguish between a busy dmeventd (takes long to respond) and dmeventd not running but FIFOs existing (I think they are never unlinked, too).
The upside is that this shouldn't matter much, because any lvm commands that need dmeventd will wait as well, and should succeed after dmeventd -R comes up (even with the delay; I test this in t-dmeventd-restart.sh).
Fixed in device-mapper-1.02.67-1.el5.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
The dmeventd, device-mapper daemon used e.g. for monitoring lvm based mirrors and snapshots, is now properly restarted during package update to fetch new versions of installed libraries.
lvm2/device-mapper regression tests passed. I also verified that this command works when dmeventd is already running. I see that this -R option is in the man page, but it is not in the help output. Should it be?
[root@grant-01 ~]# dmeventd -R
[root@grant-01 ~]# echo $?
[root@grant-01 ~]# dmeventd -h
dmeventd [-V] [-h] [-d] [-d] [-d] [-f]
-V Show version of dmeventd
-h Show this help information
-d Log debug messages to syslog (-d, -dd, -ddd)
-f Don't fork, run in the foreground
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.