Bug 167224

Summary: ifdown script not cleaning up dhcpcd-${DEVICE}.pid
Product: Red Hat Enterprise Linux 4 Reporter: Charles Lacroix <chuck>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED NEXTRELEASE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: rvokal, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://bugs.centos.org/view.php?id=998
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-31 17:57:37 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 Charles Lacroix 2005-08-31 17:50:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
I'll repaste what i already filled in the CentOS bug manager.
Since they try to stay as close as possible form EL4 i figured that
if i wanted to get a fix for this bug one day i might as well submit it
upstream. 

The bug isn't hard to reproduce but i would say it's not something that everyone will run into very often.

Steps to reproduce the bug:
 - configure 2 network interface in dhcp.
 - change one of the 2 interfaces to static ip.
 - ifdown static_interface
 - echo $? ( then you see 1 instead of 0 )

What happens is the pidof -x dhcleint will return a pid.
then the other check is to see if dhclient-${DEVICE}.pid exist
since we don't clean up after our steps it always exists.
and the command kill will return

/sbin/ifdown: line 87: kill: (45263) - No such process


Here is the bit of code that sarts near line 82.

retcode=0
if [ "$BOOTPROTO" = bootp -o "$BOOTPROTO" = dhcp ]; then
        [ -n "`pidof -x dhclient`" ] && {
                if [ -f "/var/run/dhclient-${DEVICE}.pid" ]; then
                   kill `cat /var/run/dhclient-${DEVICE}.pid` >/dev/null 2>&1
                   retcode=$?
                fi
        }
        [ -n "`pidof -x dhcpcd`" ] && {
                if [ -f "/etc/dhcpc/dhcpcd-${DEVICE}.pid" ]; then
                   kill `cat /etc/dhcpc/dhcpcd-${DEVICE}.pid` >/dev/null 2>&1
                   retcode=$?
                elif [ -f "/var/run/dhcpcd-${DEVICE}.pid" ]; then
                   kill `cat /var/run/dhcpcd-${DEVICE}.pid` >/dev/null 2>&1
                   retcode=$?
                fi
        }
        [ -n "`pidof -x pump`" ] && {
                pump -r -i ${DEVICE}
                retcode=$?
        }
else ...


The main problem here is that we do kill dhclient but we are not cleaning up
/var/run/dhclient-${DEVICE}.pid

So my way to fix this problem was tu issue a rm -f after the kill

                if [ -f "/var/run/dhclient-${DEVICE}.pid" ]; then
                   kill `cat /var/run/dhclient-${DEVICE}.pid` >/dev/null 2>&1
                   rm -f /var/run/dhclient-${DEVICE}.pid;
                   retcode=$?
                fi

and while at it we could always change it in the dhcpcd part of the script

This problem is also into RedHat Enterprise Linux 4 so it might be a good
idea to push this problem/fix upstream. I just didn't have an account with
Redhat.


Version-Release number of selected component (if applicable):
initscripts-7.93.13

How reproducible:
Always

Steps to Reproduce:

Steps to reproduce the bug:
 - configure 2 network interface in dhcp.
 - change one of the 2 interfaces to static ip.
 - ifdown static_interface
 - echo $? ( then you see 1 instead of 0 )

Actual Results:  ifdown retuns 1 when i do echo $?
and this keeps our scripts form working in a web interface.

Expected Results:  should return 0 like usual, it's due to not removing
the .pid file

Additional info:

Comment 1 Bill Nottingham 2005-08-31 17:57:37 UTC
This is fixed in the devel branch, and Fedora Core 4 - it will be fixed for RHEL 5.

Comment 2 Bill Nottingham 2005-09-01 21:33:34 UTC
*** Bug 167206 has been marked as a duplicate of this bug. ***