Bug 5694 - netstat -p symptom of how /proc/pid/* acts when process is swapped out
netstat -p symptom of how /proc/pid/* acts when process is swapped out
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: net-tools (Show other bugs)
6.1
i386 Linux
low Severity low
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-07 15:35 EDT by James Manning
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-08 10:22:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Manning 1999-10-07 15:35:52 EDT
Message from netstat -ap (*run as root*):

(Not all processes could be identified, non-owned process
info will not be shown, you would have to be root to see it
all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign
Address         State       PID/Program name
tcp        0      1 rtsa1.raleigh.ibm.:1023
vox.raleigh.ibm:printer SYN_SENT    451/lpd
[snip]
tcp        0      0 rtsa1.raleigh.ibm.:1075
serv15.raleigh.i:telnet ESTABLISHED 1919/
tcp        0      0 rtsa1.raleigh.ibm.:1074
serv15.raleigh.i:telnet ESTABLISHED 1918/telnet
[snip]

(sorry for any wrapping)

I think this means:

This is line 387 of netstat.c
  meaning prg_cache_loaded != 1

Since prg_cache_loaded is set to 1 at line 303, this appears
to mean that the prg_cache_add() from line 370 is getting
called and hence sets prg_cache_loaded to 2.  The
prg_cache_add() getting executed doesn't appear to be a big
deal since it appears to be the snprintf() call before it
that generates the ending of netstat -p output

***
After digging through and trying to find patterns, it looks
like that any process that has no resident pages in memory
(and hence "ps" stat output will show "W") has its
accompanying /proc/pid/* entries messed up... in particular,
even though this machine has 4 telnet sessions from 4
xterm's to the same machine, 3 of the 4 are swapped out and
now their cmdline is empty:

[root@rtsa1 /root]# cat /proc/{1919,2024,2040}/cmdline
[root@rtsa1 /root]#

Yes, this machine *does* swap a lot :)

[root@rtsa1 /root]# free
             total       used       free     shared
buffers     cached
Mem:         64136      61540       2596      17356
1344      24756
-/+ buffers/cache:      35440      28696
Swap:       192772     160108      32664

Hence it looks like netstat (among others) might assume
that root can always get valid /proc/*/cmdline entries,
although if processes are swapped out that's not the case.

Please feel free to reassign this to net-tools and patch
netstat.c to simply warn about this case

--- netstat.c~1~	Thu Oct  7 15:32:10 1999
+++ netstat.c	Thu Oct  7 15:33:52 1999
@@ -384,8 +384,12 @@
 		geteuid());
     }
     else
-	fprintf(stderr, _("(Not all processes could be identified,
non-owned process info\n"
-			 " will not be shown, you would have to be root to see
it all.)\n"));
+	if(geteuid())
+		fprintf(stderr, _("(Not all processes could be
identified, non-owned process info\n"
+			 	" will not be shown, you would have to be root to see
it all.)\n"));
+	else
+		fprintf(stderr, _("(Not all processes could be identified
because some were swapped out of memory\n"));
+
 }

 #if HAVE_AFNETROM
Comment 1 Cristian Gafton 2000-01-04 17:25:59 EST
Assigned to dledford
Comment 2 James Manning 2000-02-08 10:17:59 EST
Actually, it looks like the core problem is that /proc/$PID/exe,
normally symlink to the executable's place in filesystem namespace,
goes away for processes with no pages in core.
Comment 3 James Manning 2000-02-08 10:22:59 EST
Sorry, ignore that last comment, just strace'd again and netstat
*does* use /proc/pid/cmdline :)
Comment 4 Need Real Name 2001-10-31 13:32:54 EST
Closing this bug as our testing showed that this defect is not observed when tested against current 7.2 release.

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