Bug 454618
| Summary: | dmevent needs to be restarted during update | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Milan Broz <mbroz> |
| Component: | device-mapper | Assignee: | Petr Rockai <prockai> |
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.3 | CC: | agk, christophe.varoqui, cmarthal, coughlan, dwysocha, egoggin, heinzm, iannis, jbrassow, junichi.nomura, kueda, lmb, mbroz, prockai, pvrabec, qcai, tranlan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | Environment: | ||
| Last Closed: | 2012-02-21 06:01:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Milan Broz
2008-07-09 12:38:11 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. 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
%{_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.
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.
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.
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 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 |