Bug 157725 - sysctl -A returns an error
sysctl -A returns an error
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: procps (Show other bugs)
4.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Karel Zak
Brian Brock
:
Depends On:
Blocks: 158175 168429
  Show dependency treegraph
 
Reported: 2005-05-13 23:39 EDT by Ian Laurie
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2006-0036
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 11:46:52 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 Ian Laurie 2005-05-13 23:39:21 EDT
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 08:21:11 EDT
$ rpm -qf /sbin/sysctl
procps-3.2.5-4
Comment 2 Karel Zak 2005-05-17 09:19:19 EDT
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-17 21:46:52 EDT
sounds feasable to me. davem ?
Comment 4 David Miller 2005-05-18 02:07:28 EDT
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 16:22:11 EDT
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 08:06:18 EDT
It's bug in both -- kernel and procps. The procps part: bug #158175.
Comment 14 Karel Zak 2005-07-11 04:08:39 EDT
*** Bug 162881 has been marked as a duplicate of this bug. ***
Comment 15 Karel Zak 2005-07-11 04:13:13 EDT
Oops.. duplicate bug #162881 is more connected with userspace part of the
problem, it means bug #158175.
Comment 16 Karel Zak 2005-08-02 04:35:11 EDT
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 09:06:37 EDT
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 06:30:46 EDT
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 07:15:07 EDT
Yes, there have to be --w-------. See my comment #16. 
Comment 26 Dave Jones 2005-11-04 14:41:17 EST
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 05:35:39 EST
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 11:46:53 EST
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

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