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 230227

Summary: Kernel 2.6.19 changes /proc sorting
Product: [Fedora] Fedora Reporter: Tomas Hoger <thoger>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: kzak, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-01 14:09:28 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 Tomas Hoger 2007-02-27 16:36:38 UTC
Description of problem:

Current version of ps display it's output sorted according to PID, not according
to process start time as is common for Linux systems.  Therefore, once pid
counter wraps around, it's quite difficult to find newly started processed in ps
output.


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

procps-3.2.7-8.2.fc6


Steps to Reproduce:
1. Make your system wrap-around pid counter.
2. Run ps -ef and check where it appears in its output.


Additional info:

Issue was also mentioned in log for #220752 as possible cause of reported
problem.  After 2 weeks, no reaction from submitter nor maintainer, hence I
decided to open dedicated bug report.

Comment 1 Karel Zak 2007-02-27 19:19:12 UTC
Are you able to produce different output with any diffrent version of procps on
same system (kernel)? [1]

I don't think so. The ps command only follows order in /proc directory. There is
not any extra sort() in the ps command. It seems old kernels sort /proc in
differt manner than new. Try ls -fl /proc.

[1] I've tried procps-3.x and procps-2.x (upstream versions) with same results.



Comment 2 Tomas Hoger 2007-02-28 13:34:00 UTC
Thanks for quick reply!

I have tried with procps 3.0.5 (oldest I found on upstream page) and behavior is
the same.  It really seems to be /proc sorting issue ('ls -f /proc' is very good
point ;).

I have also tried different kernels:
- kernel-2.6.18-1.2798.fc6 - ok, /proc sorted as expected
- kernel-2.6.19-1.2895.fc6, kernel-2.6.19-1.2911.fc6 - new proc sorting

New questions arise:
- Is this new /proc sorting intended or bug?
- If it's intended, will procps be modified to compensate for this change?


Comment 3 Karel Zak 2007-02-28 21:44:31 UTC
It seems like a regression. Re-assigning to kernel guys.

Comment 4 Tomas Hoger 2007-03-01 09:52:56 UTC
Looks like upstream issue.  I managed to reproduce similar behavior on Gentoo
2.6.19 kernel.

ChangeLog-2.6.19 mentions several /proc -related changes by Eric W. Biederman,
maybe that's the point where it was introduced...


Comment 5 Chuck Ebbert 2007-03-01 14:09:28 UTC
From Albert Cahalan, author of procps:

    ps --sort=start_time

    I've always just assumed the order to be random. 


From Eric W. Biederman, who made the kernel change:

Apologies, but this was a bug fix for a more serious issue.  The code
to report the directory entries by start time was fundamentally broken.
In particular the sequence:
opendir
readdir
readdir
readdir
....
closedir

can miss processes that exist for the entire duration of that
sequence.  Which is non-posix, non-intuitive, and has no reasonable
work around.

The sorting by pid happened as a side effect of finding a stable token
we can come back to so we can at least guarantee normal readdir
semantics.  That objects that exist for the entire readdir are
guaranteed to be displayed.  That objects that come into existence or
are deleted during the readdir may be missed.  That isn't perfect but
it is a useable semantic. 


Comment 6 Tomas Hoger 2007-03-01 20:37:47 UTC
Chuck, thanks for reply!  It's more or less what I expected.

Btw: Those replies from Albert and Eric were taken from private communication or
from some public discussion about the issue on mailing list or forum, which I
haven't managed to find?  If later is the case, any pointers are appreciated.