Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454618 - dmevent needs to be restarted during update
Summary: dmevent needs to be restarted during update
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper
Version: 5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Petr Rockai
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-09 12:38 UTC by Milan Broz
Modified: 2013-03-01 04:06 UTC (History)
17 users (show)

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.
Clone Of:
Environment:
Last Closed: 2012-02-21 06:01:19 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0219 normal SHIPPED_LIVE device-mapper bug fix and enhancement update 2012-02-20 14:53:09 UTC

Description Milan Broz 2008-07-09 12:38:11 UTC
+++ 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 22:17:08 UTC
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 16:30:54 UTC
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 19:50:34 UTC
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 22:27:03 UTC
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 12:18:33 UTC
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 13:40:11 UTC
(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 12:59:34 UTC
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 12:13:43 UTC
Fixed in device-mapper-1.02.67-1.el5.

Comment 15 Milan Broz 2011-12-06 22:53:02 UTC
    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 15:19:19 UTC
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 $?
0


[root@grant-01 ~]# dmeventd -h
Usage:
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 06:01:19 UTC
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.

http://rhn.redhat.com/errata/RHBA-2012-0219.html


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