LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* PID entries in /proc sorted by number, not start time in 2.6.19
@ 2007-02-28 22:27 Chuck Ebbert
2007-02-28 23:39 ` Eric W. Biederman
0 siblings, 1 reply; 3+ messages in thread
From: Chuck Ebbert @ 2007-02-28 22:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Eric W. Biederman, Albert Cahalan
Starting with kernel 2.6.19, the process directories in
/proc are sorted by number. They were sorted by process
start time in 2.6.18 and earlier. This makes the output
of procps come out in that order too, pissing off users
who are used to the old way.
To reproduce:
1. Wrap your PID numbers.
2. Do ls -fl /proc
3. Look at output of ps command.
Compare 2.6.18 to 2.6.19.
See also:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230227
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PID entries in /proc sorted by number, not start time in 2.6.19
2007-02-28 22:27 PID entries in /proc sorted by number, not start time in 2.6.19 Chuck Ebbert
@ 2007-02-28 23:39 ` Eric W. Biederman
2007-03-01 1:16 ` Albert Cahalan
0 siblings, 1 reply; 3+ messages in thread
From: Eric W. Biederman @ 2007-02-28 23:39 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: linux-kernel, Albert Cahalan
Chuck Ebbert <cebbert@redhat.com> writes:
> Starting with kernel 2.6.19, the process directories in
> /proc are sorted by number. They were sorted by process
> start time in 2.6.18 and earlier. This makes the output
> of procps come out in that order too, pissing off users
> who are used to the old way.
>
> To reproduce:
> 1. Wrap your PID numbers.
> 2. Do ls -fl /proc
> 3. Look at output of ps command.
>
> Compare 2.6.18 to 2.6.19.
>
> See also:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230227
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.
Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PID entries in /proc sorted by number, not start time in 2.6.19
2007-02-28 23:39 ` Eric W. Biederman
@ 2007-03-01 1:16 ` Albert Cahalan
0 siblings, 0 replies; 3+ messages in thread
From: Albert Cahalan @ 2007-03-01 1:16 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Chuck Ebbert, linux-kernel
On 2/28/07, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Chuck Ebbert <cebbert@redhat.com> writes:
>
> > Starting with kernel 2.6.19, the process directories in
> > /proc are sorted by number. They were sorted by process
> > start time in 2.6.18 and earlier. This makes the output
> > of procps come out in that order too, pissing off users
> > who are used to the old way.
ps --sort=start_time
I've always just assumed the order to be random.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-03-01 1:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-28 22:27 PID entries in /proc sorted by number, not start time in 2.6.19 Chuck Ebbert
2007-02-28 23:39 ` Eric W. Biederman
2007-03-01 1:16 ` Albert Cahalan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).