Bug 454618 - dmevent needs to be restarted during update
dmevent needs to be restarted during update
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Petr Rockai
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2008-07-09 08:38 EDT by Milan Broz
Modified: 2013-02-28 23:06 EST (History)
17 users (show)

See Also:
Fixed In Version: device-mapper-1.02.67-1.el5
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Last Closed: 2012-02-21 01:01:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Milan Broz 2008-07-09 08:38:11 EDT
+++ This bug was initially created as a clone of Bug #454349 +++

-- Additional comment from prockai@redhat.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 prockai@redhat.com 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.
Comment 2 Petr Rockai 2010-10-04 18:17:08 EDT
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.
Comment 3 Petr Rockai 2010-10-13 12:30:54 EDT
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.
Comment 4 RHEL Product and Program Management 2011-01-11 14:50:34 EST
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.
Comment 5 RHEL Product and Program Management 2011-01-11 17:27:03 EST
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.
Comment 7 Petr Rockai 2011-02-14 07:18:33 EST
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.
Comment 9 Milan Broz 2011-03-01 08:40:11 EST
(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
%{_sbindir}/dmeventd -R 

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.
Comment 10 Petr Rockai 2011-03-02 07:59:34 EST
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).
Comment 13 Milan Broz 2011-10-17 08:13:43 EDT
Fixed in device-mapper-1.02.67-1.el5.
Comment 15 Milan Broz 2011-12-06 17:53:02 EST
    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.
    New Contents:
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.
Comment 16 Corey Marthaler 2012-01-11 10:19:19 EST
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? 

Marking verified.

[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
Comment 17 errata-xmlrpc 2012-02-21 01:01:19 EST
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.


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