Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 7578

Summary: rp3 connection status gets confused if netreport fails
Product: [Retired] Red Hat Linux Reporter: Kristopher D. Giesing <kgiesing>
Component: rp3Assignee: Michael K. Johnson <johnsonm>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-12-09 21:52:10 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 Kristopher D. Giesing 1999-12-04 06:50:33 UTC
I've been having an annoying problem for awhile with the rp3 applet.  After
connecting, I cannot disconnect because rp3 thinks there is no connection
and tries to connect again.  The tooltip and menu option are both set to
"connect to myisp" even though the connection to "myisp" is up.

I spent some time trying to figure out why, and it appears that the
permissions on /var/run/netreport/ were the problem.  The permissions for
/var/run/netreport were set to 755, so that users could not create files
there.  I set the permissions to 777 and things seem to work better.  I do
see files created by the user in that directory, so write permission seems
to be necessary:

ls -l /var/run/netreport/
total 0
----------   1 kgiesing root            0 Dec  3 22:39 6171
----------   1 root     root            0 Dec  3 22:41 6314

I didn't do anything perverse, btw - not sure why the permissions were
wrong in the first place.  Maybe using rp3 for the first time as root
created the directory, and root's umask is the culprit?

Not sure if this is a bug, but if not, better diagnostics would have been
nice (so consider this report an enhancement report :)

Regards, -- Kris

Comment 1 Michael K. Johnson 1999-12-06 20:31:59 UTC
No, you shouldn't be able to write files there as a normal user --
the netreport program is responsible for writing those files and is
setgid to make it possible to write to /var/run/netreport/

$ ls -l /sbin/netreport
-rwxr-sr-x   1 root     root         3860 Sep 26 13:49 /sbin/netreport
$ ls -ld /var/run/netreport
drwxrwxr-x   2 root     root         1024 Dec  6 12:48 /var/run/netreport
$ ls -l /var/run/netreport/
total 0
----------   1 johnsonm root            0 Nov  9 17:13 17851
----------   1 johnsonm root            0 Sep 29 11:47 804

Note that the group there is root -- because netreport is setgid

rpm -V initscripts

Comment 2 Michael K. Johnson 1999-12-07 17:57:59 UTC
I should clarify: I can't reproduce this problem.  I don't think that the
change you made had anything to do with fixing the problem, unless the
problem exists because your /sbin/netreport permissions were mangled some

If referting your change causes the problem to recurr, I suggest
rpm -V initscripts
to see what it says, and
ld -l /sbin/netreport
to make sure it is setgid root.  I'd also suggest finding the pid of
your rp3 binary and seeing if /var/run/netreport/<pid> exists.

Comment 3 Kristopher D. Giesing 1999-12-09 07:25:59 UTC
Reverting the permissions to 755 (as they were originally) caused the problem to
resurface.  Changing the permissions to 775 (as you have in your comment) caused
the problem to go away again.

Here's what I see on my (now-working) system:

[kgiesing@uvula ~]$ ls -ld /var/run/netreport
drwxrwxr-x   2 root     root         4096 Dec  8 23:20 /var/run/netreport
[kgiesing@uvula ~]$ ls -l /var/run/netreport
total 0
----------   1 kgiesing root            0 Dec  8 23:16 2818
----------   1 root     root            0 Dec  8 23:20 3094
[kgiesing@uvula ~]$ ps aux | grep rp3
kgiesing  2818  0.1  5.4  6000 3420 ?        S    23:16   0:00 rp3
--activate-gokgiesing  3145  0.0  0.7  1240  492 pts/0    S    23:21   0:00 grep
[kgiesing@uvula ~]$ ps aux | grep ppp
root      3094  0.0  0.6  1104  432 ?        S    23:20   0:00 /sbin/ppp-watch
iroot      3096  0.1  1.4  1788  932 ttyS2    S    23:20   0:00 /usr/sbin/pppd
-dkgiesing  3147  0.0  0.7  1240  492 pts/0    S    23:21   0:00 grep ppp
[kgiesing@uvula ~]$ rpm -V initscripts
S.5....T c /etc/inittab
S.5....T c /etc/rc.d/rc.local
[kgiesing@uvula ~]$ ls -l /sbin/netreport
-rwxr-sr-x   1 root     root         3860 Sep 26 10:49 /sbin/netreport

In any case, my enhancement suggestion is to trap the error that netreport was
failing, and pop up a dialog.  I'm running the rp3 applet in the gnome panel, so
I didn't see anything printed to stderr; I was running rp3 from an xterm during
debugging when I noticed that netreport was failing.

Comment 4 Michael K. Johnson 1999-12-09 21:52:59 UTC
/var/run/netreport should be 775 -- that's what it is in every package I
can find.

rp3 should not be concerned with the permissions on /var/run/netreport --
if the netreport program later is switched to a different registration
methodology, we don't want angry warning messages showing up in rp3.
Fix each bug where it is...