Bug 157725

Summary: sysctl -A returns an error
Product: Red Hat Enterprise Linux 4 Reporter: Ian Laurie <nixuser>
Component: procpsAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 4.0CC: davej, davem, jos, kzak, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2006-0036 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-07 16:46:52 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: 158175, 168429    

Description Ian Laurie 2005-05-14 03:39:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Red Hat/1.0.3-1.4.1 Firefox/1.0.3

Description of problem:
The command 'sysctl -a' or 'sysctl -A' produces a listing that contains
some errors as follows:

error: unknown error 22 reading key 'net.ipv6.route.flush'
error: unknown error 22 reading key 'net.ipv4.route.flush'
error: unknown error 22 reading key 'fs.binfmt_misc.register'


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


How reproducible:
Always

Steps to Reproduce:
1. Issue the command 'sysctl -a | grep error'
2. Observe the errors that appear.
3.
  

Actual Results:  Three errors appear in the listing.

Expected Results:  I would not expect there to be errors.

Additional info:

Standard RHEL4 system, all errata applied.

Fedora Core 3 seems to have the same problem.  RHEL3 appears to be OK.

Comment 1 Harald Hoyer 2005-05-17 12:21:11 UTC
$ rpm -qf /sbin/sysctl
procps-3.2.5-4


Comment 2 Karel Zak 2005-05-17 13:19:19 UTC
See Bug 144459 รข sysctl reports error: unknown error <...> reading key '<key>'

It's fixed in FC4. The full fix require small change in kernel too. I'm not sure
if we want to do it in the old kernels too. It might be a regression problem
with modes in /proc.

Dave, what's your opinion (<=RHEL4)?

Comment 3 Dave Jones 2005-05-18 01:46:52 UTC
sounds feasable to me. davem ?


Comment 4 David Miller 2005-05-18 06:07:28 UTC
I think backporting the fix into <=RHEL4 is fine.

DaveJ, it's just the patch you posted to netdev and
me a while ago that fixes the ipv4/ipv6 flush file
permissions right?  If so, just apply it :-)



Comment 6 Dave Jones 2005-05-18 20:22:11 UTC
yep. Karel, feel free to reassign this as a kernel bug to me once you've done
the necessary changes to procps in U2.

thanks.


Comment 7 Karel Zak 2005-05-19 12:06:18 UTC
It's bug in both -- kernel and procps. The procps part: bug #158175.

Comment 14 Karel Zak 2005-07-11 08:08:39 UTC
*** Bug 162881 has been marked as a duplicate of this bug. ***

Comment 15 Karel Zak 2005-07-11 08:13:13 UTC
Oops.. duplicate bug #162881 is more connected with userspace part of the
problem, it means bug #158175.

Comment 16 Karel Zak 2005-08-02 08:35:11 UTC
It seems there is more files with the same problem:

2.6.9-11.34.EL:

$ ls -la /proc/sys/dev/parport/parport0/autoprobe*
-r--r--r--  1 root root 0 Aug  2 04:29 /proc/sys/dev/parport/parport0/autoprobe
-r--r--r--  1 root root 0 Aug  2 04:29 /proc/sys/dev/parport/parport0/autoprobe0
-r--r--r--  1 root root 0 Aug  2 04:29 /proc/sys/dev/parport/parport0/autoprobe1
-r--r--r--  1 root root 0 Aug  2 04:29 /proc/sys/dev/parport/parport0/autoprobe2
-r--r--r--  1 root root 0 Aug  2 04:29 /proc/sys/dev/parport/parport0/autoprobe3


2.6.12-1.1385_FC4:

# ls -la /proc/sys/dev/parport/parport0/autoprobe*
--w-------  1 root root 0 Aug  2 10:22 /proc/sys/dev/parport/parport0/autoprobe
--w-------  1 root root 0 Aug  2 10:22 /proc/sys/dev/parport/parport0/autoprobe0
--w-------  1 root root 0 Aug  2 10:22 /proc/sys/dev/parport/parport0/autoprobe1
--w-------  1 root root 0 Aug  2 10:22 /proc/sys/dev/parport/parport0/autoprobe2
--w-------  1 root root 0 Aug  2 10:22 /proc/sys/dev/parport/parport0/autoprobe3



Comment 21 Red Hat Bugzilla 2005-10-05 13:06:37 UTC
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/RHSA-2005-514.html


Comment 22 Keiichi Mori 2005-10-20 10:30:46 UTC
This issue still happens on kernel-2.6.9-22.EL:

# uname -r
2.6.9-22.ELsmp
# sysctl -a > /dev/null
error: unknown error 25 reading key 'dev.parport.parport0.autoprobe3'
error: unknown error 25 reading key 'dev.parport.parport0.autoprobe2'
error: unknown error 25 reading key 'dev.parport.parport0.autoprobe1'
error: unknown error 25 reading key 'dev.parport.parport0.autoprobe0'
error: unknown error 25 reading key 'dev.parport.parport0.autoprobe'
error: unknown error 25 reading key 'dev.parport.parport0.devices.lp.timeslice'

# cd /proc/sys/dev/parport/parport0/
# ls -l autoprobe*
-r--r--r--  1 root root 0 Oct 20 10:30 autoprobe
-r--r--r--  1 root root 0 Oct 20 10:30 autoprobe0
-r--r--r--  1 root root 0 Oct 20 10:30 autoprobe1
-r--r--r--  1 root root 0 Oct 20 10:30 autoprobe2
-r--r--r--  1 root root 0 Oct 20 10:30 autoprobe3
# cd devices/lp
# ls -l timeslice
-rw-r--r--  1 root root 0 Oct 20 10:32 timeslice

Should those entries also be set to --w------- ?


Comment 23 Karel Zak 2005-10-20 11:15:07 UTC
Yes, there have to be --w-------. See my comment #16. 

Comment 26 Dave Jones 2005-11-04 19:41:17 UTC
that file shouldn't be --w------- at all. It's read only.
however, it only outputs data if theres actually a printer connected.
(Thats my understanding from reading the code at least).

I don't see anything obviously wrong in the kernel side. Can you check that
procps handles the case where we return success, but no data correctly ?

What's really bizarre is that on my rawhide box, this problem still exists, but
I can make it expose itself in different ways depending on where I pipe the output..

(14:39:21:root@nwo:~)# sysctl -a > /dev/null
error: "Inappropriate ioctl for device" reading key
"dev.parport.parport0.autoprobe3"
error: "Inappropriate ioctl for device" reading key
"dev.parport.parport0.autoprobe2"
error: "Inappropriate ioctl for device" reading key
"dev.parport.parport0.autoprobe1"
error: "Inappropriate ioctl for device" reading key
"dev.parport.parport0.autoprobe0"
error: "Inappropriate ioctl for device" reading key "dev.parport.parport0.autoprobe"
error: "Inappropriate ioctl for device" reading key
"dev.parport.parport0.devices.lp.timeslice"


(14:42:37:root@nwo:~)# sysctl -a | head -n1
error: "Success" reading key "dev.parport.parport0.autoprobe3"
error: "Success" reading key "dev.parport.parport0.autoprobe2"
error: "Success" reading key "dev.parport.parport0.autoprobe1"
error: "Success" reading key "dev.parport.parport0.autoprobe0"
error: "Success" reading key "dev.parport.parport0.autoprobe"
error: "Success" reading key "dev.parport.parport0.devices.lp.timeslice"


Comment 27 Karel Zak 2005-11-08 10:35:39 UTC
Sorry, it's user space problem now. The sysctl code expects that fgets()==NULL
is error, but it could be empty file too.

Comment 35 Red Hat Bugzilla 2006-03-07 16:46:53 UTC
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/RHBA-2006-0036.html