Bug 693475

Summary: fuser does not correctly identify IPv6 sockets
Product: Red Hat Enterprise Linux 5 Reporter: Joel Davis <jodavis>
Component: psmiscAssignee: Jan Görig <jgorig>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: low Docs Contact:
Priority: unspecified    
Version: 5.6   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-04 19:57:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Joel Davis 2011-04-04 19:07:57 UTC
Description of problem:
In RHEL 5.5 fuser recognizes IPv6 sockets as IPv4 meaning that "fuser -d tcp <portNum>" returns expected output but "fuser -6 -d tcp <portNum>" does not. Running "fuser -4 -d tcp <portNum>" returns the PID associated with the port. In RHEL 5.6 neither -4 or -6 options return the PID. Users can work around the issue by grepping the output of an "lsof -Pi" command.

Version-Release number of selected component (if applicable):
psmisc-22.2

How reproducible: Through the following steps:

Steps to Reproduce (on RHEL 5.6):
1. bind to an available tcp port using IPv6 (attached the python script I was using to reproduce.)
2. run "fuser -d tcp <portNum>" ("fuser -d tcp 8080" with the attached script)
  
Actual results:
User is returned to prompt with no output to the console.

Expected results:
Output similar to: 8080/tcp: 20867

Additional info:
netstat and lsof both show the port as being IPv6
Appears to be reproducible on 32bit and 64bit
Also reproducible on RHEL6's psmisc-22.3

It appears that the problem was identified upstream and already fixed in the psmisc-22.11 release:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581604

Also, newer fedora's seem to be using psmisc-22.13

Comment 1 Joel Davis 2011-04-04 19:57:01 UTC

*** This bug has been marked as a duplicate of bug 693476 ***