Bug 165770
Summary: | rm: cannot remove '/var/run/tog-pegasus/socket': Is a directory | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Ben Levenson <benl> |
Component: | tog-pegasus | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | jorton, notting |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | RHEA-2005-494 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-10-05 13:43:29 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: | |||
Bug Depends On: | |||
Bug Blocks: | 156322 |
Description
Ben Levenson
2005-08-11 22:11:50 UTC
I noticed that most of the other *socket* files in /var/run don't live in their own directory. Is tog-pegasus going against convention here? Well, it looks like there are some exceptions built into rc.sysinit for this (@ line 792): --- # Clean up /var. I'd use find, but /usr may not be mounted. for afile in /var/lock/* /var/run/* ; do if [ -d "$afile" ]; then case "$afile" in */news|*/mon) ;; */sudo) rm -f $afile/*/* ;; */vmware) rm -rf $afile/*/* ;; */samba) rm -rf $afile/*/* ;; *) rm -f $afile/* ;; esac else rm -f $afile fi done --- In future, it would be nice to have an exception in rc.sysinit for tog-pegasus. I'll make tog-pegasus' initscript's 'stop' handler do a 'rm -rf /var/run/tog-pegasus' for the next version (tog-pegasus-2.4.1-2+) - this is now in CVS. changed component to tog-pegasus. That's a workaround more than a fix -- after an unclean shutdown (i.e. power loss) the message will still appear on next boot. This is now fixed with latest tog-pegasus-2.4.1-2.rhel4 version : cimserver no longer creates the /var/run/tog-pegasus/socket/ directory, but puts its socket in /var/run/tog-pegasus . It is RHEA-2005:494 that needs the respin (also for bug 165803). The new tog-pegasus release also fixes Bug 165803 and Bug 165880. I think it is better to start out with the new tog-pegasus release since it will be our first distribution of the package, but this is up to PM. Yes, this issue may remain after upgrade or erase+install from tog-pegasus-2.4.1-1 to the fixed tog-pegasus-2.4.1-2.rhel-4 release . But after a clean install of tog-pegasus-2.4.1-2.rhel4+, as would occur when RHEL-4 customers receive the tog-pegasus-2.4.1-2.rhel4 for the first time through the RHN channels, this problem would not occur. The problem is this: the tog-pegasus-2.4.1-1 release did not list the /var/run/tog-pegasus/socket directory in its %files list (it did not Provide: it), so it was not removed when tog-pegasus-2.4.1-1 was erased. This problem was fixed with tog-pegasus-2.4.1-2.rhel4+: the package now lists /var/run/tog-pegasus in its %files list, and the directory would be removed when erasing tog-pegasus-2.4.1-2+ . Because it is VERY bad practice for any RPM scriplet to do a 'rm -rf' of ANY directory, as did tog-pegasus-2.4.1-1 with the /opt/tog-pegasus directory (but not /var/run/tog-pegasus/socket!) we do not want to make tog-pegasus-2.4.1-2 do this during install / upgrade - who knows what some user might have put in this directory? This issue was inherited from the upstream tog-pegasus release, which still has this behaviour, though the tog-pegasus maintainers are committed to resolving it in subsequent releases. So, I'm sorry - you'll need to 'rm -rf /var/run/tog-pegasus/socket' to prevent this message occuring . After this, all subsequent upgrades / installs will not result in the message reappearing. Any user who clean installs to tog-pegasus-2.4.1-2+, as would all non-beta customers, will not experience this problem. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2005-494.html |