Bug 167723 - 'renice(1)' documentation allows 'renice -n 4 -p $$' but resets PID 4 nice value on i386 FC4 load on i686
Summary: 'renice(1)' documentation allows 'renice -n 4 -p $$' but resets PID 4 nice va...
Alias: None
Product: Fedora
Classification: Fedora
Component: man-pages   
(Show other bugs)
Version: 4
Hardware: i686 Linux
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-09-07 16:43 UTC by roy a. crabtree
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-22 07:04:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description roy a. crabtree 2005-09-07 16:43:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Red Hat/1.0.4-1.4.1 Firefox/1.0.4

Description of problem:
Is this a documentation bug, 
or a fundamental error in loading 
that ought to be trapped on?

   rpm -qif did not find renice.

Ran on one system a cold full FC4 i386 load, then yummed it all on one box; 
ran on another an AS i386 update over FC3 latest then yummed it.

Both maintained the same bug.

Documentation has the expected arguments to "renice(1)".


renice -n 4 -p 10968

RESET nice value on PID 4, and did NOT find PID 10968, which DID exist;
which the manual page _and_ info both allow.

renice 4 -p 10968

DID work (finally).

however, a bug in the command line scan of renice will harm other processes when running as root; so this is:

A)  A bug in the load sequence where Redhat should force/note an
  architectural (i386/i586/i686/ia64) mismatch or better fit,

B)  An emulation package should be available and default installed/loaded
  for use (either to run emulations, or allow an error trap) when
  a binary package _could_ be made to run correctly, and to stop it
  from doing so when the systems administtrator does not wish to

   Example:  Run a 64 bit application on a 32bit system when no other way;
   run an EMD64 build on an i686 system as a test sequence for a demo
   of the i686 system emulation speeds, or an i386 build on an ia64
   system for older legacy packages, or trap and warn the users NOT to do so.


C)  'renice(1)' documentation is incorrect and needs fixing AND:

D) 'renice(1)' will incorrectly modify a process priority as root
   if run with the arguments as given on themanual page, or even
   just your own if you mismatch the PID numbers by chance.

    Unfortunately, low PID numbers tend to be critical systems processes;

   so I would regard this last case as SEVERE and CRITICAL.

Sorry for the complex analysis; I do not have the time to run it down by rebuilding the systems involved.

the complexity of the "Easy ISO" sequences among many similar but not the same architecture and load ocnfiguration packages can easily lead to this problem,

ESPECIALLY if a set of load CDs is mislabelled or grabbed incorrectly, or the 'yum(1)' repositories are pointed to the wrong channels.


Version-Release number of selected component (if applicable):
latest plus latest patches: coreutils-5.2.1-31.1 over -31.

How reproducible:

Steps to Reproduce:
1. Ran renice to lower a yum download (jerky X11 mouse on a 900 MHz box)
2. Failed with the message no such process 10968
3. Looked up the man and info and saw what I expected
4.  Ran all possible combinations; only:

  renice N -p PID

worked correctly: as root

   renice -n 4 -p 10968

altered the priority or PID 4, and di NOT find PID 10968.

Actual Results:  PID 4 had its nice value changed incorrectly with the '-n' flag as described.

reproducible across multiple systems and reboots 100%

Expected Results:  PID 10968 should have its nice value shifted to 4.

Additional info:

I would expect a variant architectural load among similar classes of machines, or a variant update among different packagings (FC3 to FC4 WS cold, FC3 WS to FC4 AS update) would prompt for _any_ failure combination that could occur, and/or make the resulting combination work correctly, or be configurable to be trapped as improper (HW emulations) from the get go.

  I will note that yum does not catch this type of shift;
  if not validly allowed, it _should_ because _another_
  systems administrator set all this up ...

   and architectural shifts of this type are as old as OS distributions.

The default behavior ought to be, if you load it:

    1) It works.
    2) It tells you if there is a faster way to do it.
    3) it warns you FIRST before doing ANYTHING other than
       EXACTLY the correct load, and 
    4) IT TELLS you which way that is, and
    5) IT TELLS YOU when and where and how to get it.

Why allow other combinations?

- Emulations of legacies
- Demonstration of emulaiton speeds
- The user does not have any other load method available
- Demonstration of expertise in tracking down problems
  for training ysstem administrators (evil grin).

Security issue:  A system process can be easily impacted in a way that cripples system safeguards if it's priority is altered improperly.

And so forth.

Draw an error propagation tree and you will see what I mean.

A decision table will give you the full set of combinations,
and allow RedHat to come up with a policy analysis table.


PS:  I would have been working for you over the last three years if you had hired me.

Comment 1 Tim Waugh 2005-09-07 17:10:39 UTC
The renice we ship (as run from the command line you gave) comes from util-linux:

$ type renice
renice is /usr/bin/renice
$ rpm -qf /usr/bin/renice

Comment 2 Karel Zak 2005-09-08 07:33:30 UTC
It's a man page problem. There's two man pages for same thing: renice(1p)
(=POSIX version) and renice(8). The second one is correct. The problem is fixed
in FC5 where is no renice.1p. I vote for same solution in FC4 :-)

BTW, see 'man 8 renice':

   renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]

Comment 3 Fedora Update System 2005-09-21 16:30:07 UTC
From User-Agent: XML-RPC

man-pages-1.67-8 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

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