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)".

However:

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.

   Or:

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.

Cheers.

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

How reproducible:
Always

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.

Cheers.

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