I am ecstatic beyond words to announce the release of procps version
2.0.13. This release contains a number of NPTL-related enhancements,
courtesy of Alexander Larsson of Red Hat. Some of the enhancements are
generic in nature, and thus also benefit non-NPTL applications.
I encourage everyone to give this a try, especially 2.5 users.
Tarball, RPM packages, and CVS information is available at:
http://tech9.net/rml/procps/
http://sources.redhat.com/procps/
Change Log:
- fix top(1) -p flag behavior (Lars Holmberg)
- do not qsort the process list if we are not sorting
(Alexander Larsson)
- read tgid from /proc/pid/status if it exists
(Alexander Larsson)
- PROC_SKIPTHREADS flag for ps_readproc() to force only
reading of (tgid != pid) to avoid lots of syscalls
(Alexander Larsson)
- Look at PM->flags in ps_readproc() to avoid reading
/proc files files that are not needed. (Alexander Larsson)
- Support FILLMEM, FILLCMD, FILLENV, FILLWCHAN for above.
(Alexander Larsson)
- Fix wchan decoding bug (Alexander Larsson)
- Fix for ticks going backward and cleanup (Denis Vlasenko)
And other misc. cleanups and changes.
Enjoy,
Robert "Why the Hell am I maintaining this" Love
Any comment on the procps v3.1.8 located here:
http://procps.sourceforge.net/
Seems it is actively maintained...
-Phil
On Wed, May 28, 2003 at 03:09:10PM +0000, Robert Love wrote:
> I am ecstatic beyond words to announce the release of procps version
> 2.0.13.
>
> Robert "Why the Hell am I maintaining this" Love
On Wed, 2003-05-28 at 23:19, Phil Oester wrote:
> Any comment on the procps v3.1.8 located here:
>
> http://procps.sourceforge.net/
>
> Seems it is actively maintained...
It is a fork of the original procps tree.
The maintainer of that tree will tell you his is better. I do not want
to argue it.
Robert Love
In article <1054138948.783.179.camel@localhost>,
Robert Love <[email protected]> wrote:
>On Wed, 2003-05-28 at 23:19, Phil Oester wrote:
>
>> Any comment on the procps v3.1.8 located here:
>>
>> http://procps.sourceforge.net/
>>
>> Seems it is actively maintained...
>
>It is a fork of the original procps tree.
Well, you could also argue that the current 2.0 tree is a
retroactive fork of an older version of procps.
I don't understand why you don't work together.
Mike.
--
.. somehow I have a feeling the hurting hasn't even begun yet
-- Bill, "The Terrible Thunderlizards"
Miquel van Smoorenburg wrote:
>In article <1054138948.783.179.camel@localhost>, Robert Love <[email protected]> wrote:
>>On Wed, 2003-05-28 at 23:19, Phil Oester wrote:
>>
>>> Any comment on the procps v3.1.8 located here:
>>>
>>> http://procps.sourceforge.net/
>>>
>>> Seems it is actively maintained...
>>
>>It is a fork of the original procps tree.
>Well, you could also argue that the current 2.0 tree is a
>retroactive fork of an older version of procps.
>I don't understand why you don't work together.
--from the http://procps.sourceforge.net/faq.html --
Why are there so many procps projects?
The original maintainer seems to have had little time for procps.
Whatever his reasons, the project didn't get maintained. Starting
in 1997, Albert Cahalan wrote a new ps program for the package.
For the next few years, Albert quietly helped the Debian package
maintainer fix bugs. In 2001, Rik van Riel decided to do something
about what appeared to be the lack of a maintainer. He picked up
the buggy old code in Red Hat's CVS and started adding patches.
Meanwhile, other people have patched procps in a great many ways.
In 2002, Albert moved procps to this site. This was done to ensure
that years of testing and bug fixes would not be lost. The major
version number was changed to 3, partly to avoid confusing users
and partly because the top program has been redone.
--end--
I think too that is to waste the time&resources to have two,
and to do a little different some LiNUX distributions in a basic
and important package
but if both have freetime... ;-)
regards,
--
Software is like sex, it's better when it's bug free.
On Thu, May 29, 2003 at 07:25:03PM +0200, Xose Vazquez Perez wrote:
>
> --from the http://procps.sourceforge.net/faq.html --
> Why are there so many procps projects?
>
> The original maintainer seems to have had little time for procps.
> Whatever his reasons, the project didn't get maintained. Starting
> in 1997, Albert Cahalan wrote a new ps program for the package.
> For the next few years, Albert quietly helped the Debian package
> maintainer fix bugs. In 2001, Rik van Riel decided to do something
> about what appeared to be the lack of a maintainer. He picked up
> the buggy old code in Red Hat's CVS and started adding patches.
> Meanwhile, other people have patched procps in a great many ways.
> In 2002, Albert moved procps to this site. This was done to ensure
> that years of testing and bug fixes would not be lost. The major
> version number was changed to 3, partly to avoid confusing users
> and partly because the top program has been redone.
> --end--
>
> I think too that is to waste the time&resources to have two,
> and to do a little different some LiNUX distributions in a basic
> and important package
>
> but if both have freetime... ;-)
Well, since I read Albert Cahalan's comment in Debian bug #172735 [1]
I understand the people maintaining a different branch...
> regards,
cu
Adrian
[1] http://bugs.debian.org/172735
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 2003-05-29 at 18:08, Adrian Bunk wrote:
> Well, since I read Albert Cahalan's comment in Debian bug #172735 [1]
> I understand the people maintaining a different branch...
Exactly.
That bug is fixed in the official tree, fyi. A segfault, as you said, is
always a bug. An error message is displayed.
Once that bug is fixed, he will probably find that the inability to read
files in /proc also causes a crash. Such is the problem with this
duplicated effort. It sucks. I told Albert I would be happy to merge
each and every (sane) change he sends me. He refuses. To be fair, I also
refuse to work under his tree. His comments on this list is part of the
reason. For what its worth, he did not fork off and create his tree
until Rik starting work on the official tree.
In the end, all that matters to me really is that Red Hat and other big
distributions use my tree (apparently whether I maintain it or not) and
I use those distributions. If I used Debian, maybe my view would be
different. Or maybe I would make them switch trees :)
Robert Love
On Thu, May 29, 2003 at 08:08:31PM +0200, Adrian Bunk wrote:
> Well, since I read Albert Cahalan's comment in Debian bug #172735 [1]
> I understand the people maintaining a different branch...
>
> [1] http://bugs.debian.org/172735
and http://bugs.debian.org/169398
same kind of comment :\
--
Tab
On Thu, 2003-05-29 at 20:01, Vincent Hanquez wrote:
> and http://bugs.debian.org/169398
>
> same kind of comment :\
Hah, just what I said :)
Both the unreadable bug and the not mounted bug are fixed at
http://tech9.net/rml/procps
Robert Love
Robert Love writes:
On Thu, 2003-05-29 at 18:08, Adrian Bunk wrote:
>> Well, since I read Albert Cahalan's comment in
>> Debian bug #172735 [1] I understand the people
>> maintaining a different branch...
>
> Exactly.
>
> That bug is fixed in the official tree, fyi.
> A segfault, as you said, is always a bug.
> An error message is displayed.
You asked for it...
Nice cheapshot there. So, if I remove some
critical kernel interfaces from your system,
nothing should crash? How about I take out
a few choice system calls or a chunk of libc?
(note: the "bug" is not exploitable)
Face it. For nearly a decade, /proc has been
a critical kernel interface. This isn't 1991.
(embedded systems excepted; they don't use procps)
That said, I may do something about the issue
simply to please users with messed-up systems.
> Once that bug is fixed, he will probably find
> that the inability to read files in /proc also
> causes a crash. Such is the problem with this
> duplicated effort. It sucks.
I could tell you about some inputs that
make your programs crash... Nah. Find them
yourself. I wait for your screams. >:-)
You finally fixed a SEGV that I fixed well
over a year ago. Congradulations. You have
others to fix, and a minor (?) security
issue as well. Have fun.
Oooh... I think you have an exploitable
buffer overflow as well. Anybody running
his procps as an i386 binary on IA-64?
> I told Albert I
> would be happy to merge each and every (sane)
> change he sends me. He refuses. To be fair,
> I also refuse to work under his tree. His comments
> on this list is part of the reason. For what its
> worth, he did not fork off and create his tree
> until Rik starting work on the official tree.
Nope. Rik's activity was one of two reasons
for me to increment the major number, and one
of many reasons to put the project on SourceForge.
Prior to that, I had provided 2.x.x versions
to Debian for years. Also note that I wrote
the ps program itself and a large portion of
the library you use. This all was long before
you and Rik touched procps.
Go ahead and check the 2.x.x in Debian. It's mine.
> In the end, all that matters to me really is that
> Red Hat and other big distributions use my tree
> (apparently whether I maintain it or not) and I
> use those distributions. If I used Debian, maybe
> my view would be different. Or maybe I would make
> them switch trees :)
You: Connectiva, Red Hat
Me: Debian, Slackware, SuSE, Mandrake, Rock, LFS, Gentoo...
No wonder. Your "NPTL enhancements" depend on
kernel patches that Red Hat uses. For regular
non-NPTL threads, you get this nice fat bug:
(and an "I told you so" -- you KNEW about it)
------------------------------------------------------------
From: Yakov Lerner
To: [email protected]
Subject: 'ps -C name' without -m shows all threads of the process ?
Date: Mon, 05 May 2003
We have multithreaded process with number of threads
between 20 and 60 [and changing sometimes]. This is RedHat 8.
Suddenly out of blue, 'ps -C OurprOc' started
to show all threads of the process instead of 1 line.
'ps -l -C xxx' also showed many lines -- 1 per thread
-- although expected to show 1 line only. Looking at PPIDs
in 'ps -l -C xxx' -- it's definitely all threads of a single process.
Then, 10 minutes after, 'ps -C OurprOc' reverted
to normal: showing 1 line. There is no alias of ps to 'ps -m'
or like. The process was not even restarted, same pid. It has now
74 threads.
BTW: when ps showed incorrect output, the system was highly loaded,
and when ps reverted to normal, the load subsided. I don't know
it it's related.
Is this known bug in ps ?
----------------------------------------------------------------
IMHO, important system programs don't exhibit
random behavior like that. If they do, you fix
it damn quick. You don't go and add unstable hacks
even after you've been warned... but you did.
A maintainer should say "NO" to cool new features
that come with obviously unfixable serious bugs.
On Fri, May 30, 2003 at 01:00:54AM -0400, Albert Cahalan wrote:
> Robert Love writes:
> On Thu, 2003-05-29 at 18:08, Adrian Bunk wrote:
>
> >> Well, since I read Albert Cahalan's comment in
> >> Debian bug #172735 [1] I understand the people
> >> maintaining a different branch...
> >
> > Exactly.
> >
> > That bug is fixed in the official tree, fyi.
> > A segfault, as you said, is always a bug.
> > An error message is displayed.
>
> You asked for it...
>
> Nice cheapshot there. So, if I remove some
> critical kernel interfaces from your system,
> nothing should crash? How about I take out
> a few choice system calls or a chunk of libc?
>
> (note: the "bug" is not exploitable)
>
> Face it. For nearly a decade, /proc has been
> a critical kernel interface. This isn't 1991.
> (embedded systems excepted; they don't use procps)
>
> That said, I may do something about the issue
> simply to please users with messed-up systems.
>...
Disabling the proc filesystem is simple by unchecking one item in the
kernel config menu and different from taking out "a chunk of libc" it's
more or less supported.
I don't say #172735 is exploitable. An error message "Error: /proc isn't
mounted" tells you what is wrong, a segmentation fault tells you
_nothing_.
I've seen at several occasions that several man days were lost trying to
find problems in other programs that caused segmentation faults. In the
end things like diff'ing strace files give you important hints after
hours of clueless searching. Error messages instead of segmentation
faults would have prevented several fruitless hours in my live.
After reading the last sentence you might perhaps understand my opinion
about the quality of a software whose maintainer says about a
segmentation fault "Crashing is kind of a good thing even. ... In error
checking, there is a certain balance to achieve." .
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
>>> Well, since I read Albert Cahalan's comment in
>>> Debian bug #172735 [1] I understand the people
>>> maintaining a different branch...
>>
>> Exactly.
>>
>> That bug is fixed in the official tree, fyi.
>> A segfault, as you said, is always a bug.
>> An error message is displayed.
>
>You asked for it...
>
>Nice cheapshot there. So, if I remove some
>critical kernel interfaces from your system,
>nothing should crash? How about I take out
>a few choice system calls or a chunk of libc?
It is not the same thing, I think that you
agree on that, too.
>(note: the "bug" is not exploitable)
>
>Face it. For nearly a decade, /proc has been
>a critical kernel interface. This isn't 1991.
>(embedded systems excepted; they don't use procps)
>
>That said, I may do something about the issue
>simply to please users with messed-up systems.
In my opinion, you have to do something about
the issue, because it is a bug, it is not
a missing feature. But this is just my opinion,
you are the maintainer, you take decisions.
>> Once that bug is fixed, he will probably find
>> that the inability to read files in /proc also
>> causes a crash. Such is the problem with this
>> duplicated effort. It sucks.
>
>I could tell you about some inputs that
>make your programs crash... Nah. Find them
>yourself. I wait for your screams. >:-)
'Find them yourself', nice answer ;-(
It is a pity read this kind of comment,
I still don't understand the reasons
of this duplications of code and the reason
of this kind of silly sarcastic remarks.
>You finally fixed a SEGV that I fixed well
>over a year ago. Congradulations. You have
>others to fix, and a minor (?) security
>issue as well. Have fun.
Again, you know there is a problem but you
don't say anything about it.
You do not want to fix it, don't you ?
This is fine with me (even if it is hard to
understand the reason), but you are just
/wrong/ when you know about a problem and
don't provide information about it.
Again, this is just my opinion...
>Oooh... I think you have an exploitable
>buffer overflow as well. Anybody running
>his procps as an i386 binary on IA-64?
Ditto.
Ciao,
Paolo
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
Hi,
Can someone tell me which are the source files that implement the VFS and
DEVFS???
Best regards,
Chris.
Hi,
Can someone tell me which are the source files that implement the VFS and
DEVFS???
Best regards,
Chris.
Albert Cahalan wrote:
>> On Thu, 2003-05-29 at 18:08, Adrian Bunk wrote:
>
>>Once that bug is fixed, he will probably find
>>that the inability to read files in /proc also
>>causes a crash. Such is the problem with this
>>duplicated effort. It sucks.
>
>
> I could tell you about some inputs that
> make your programs crash... Nah. Find them
> yourself. I wait for your screams. >:-)
>
> You finally fixed a SEGV that I fixed well
> over a year ago. Congradulations. You have
> others to fix, and a minor (?) security
> issue as well. Have fun.
>
> Oooh... I think you have an exploitable
> buffer overflow as well. Anybody running
> his procps as an i386 binary on IA-64?
>[...]
Mine is longer, I have more hair, less tummy...
please, stop your childish nonsense.
A fork has sense if latter the code are going to merge
(like gcc/egcs, xfree/xwin, linux/ac/mm/aa/osdl...)
or the proyect are going to take another goal.
But to have two proyects, same code(more or less),
same goal. And it's worse for to be a base crical
package. Its's waste time/resources and to do a little
different every distribution.
-thank you-
regards,
--
Software is like sex, it's better when it's bug free.
Paolo Ciarrocchi wrote:
>>You finally fixed a SEGV that I fixed well
>>over a year ago. Congradulations. You have
>>others to fix, and a minor (?) security
>>issue as well. Have fun.
>
> Again, you know there is a problem but you
> don't say anything about it.
> You do not want to fix it, don't you ?
> This is fine with me (even if it is hard to
> understand the reason), but you are just
> /wrong/ when you know about a problem and
> don't provide information about it.
> Again, this is just my opinion...
the root of the problem is that not all
packages maintainers of distributions send feedback/fixes
to _origianl software writer_. And you have cases
like this. Diferents tastes from same software,
everyone with its bugs and features.
Without to go too far, there are a lot of stupid
fixes into distributions kernels not present in 2.4.21-rcX
This is a general problem, and IMHO the distributions maintainers
should send more feedback to package maintainer more frequently.
-thanks-
regards,
--
Software is like sex, it's better when it's bug free.
On Fri, 2003-05-30 at 12:37, Xose Vazquez Perez wrote:
> Mine is longer, I have more hair, less tummy...
>
> please, stop your childish nonsense.
>
> A fork has sense if latter the code are going to merge
> (like gcc/egcs, xfree/xwin, linux/ac/mm/aa/osdl...)
> or the proyect are going to take another goal.
>
> But to have two proyects, same code(more or less),
> same goal. And it's worse for to be a base crical
> package. Its's waste time/resources and to do a little
> different every distribution.
You've made your point, here and elsewhere.
Both parties involved disagree. I suggest
you spend your efforts elsewhere:
OpenBSD should merge with NetBSD.
XEmacs should merge with GNU Emacs.
CinePaint should merge with The Gimp.
Windows should merge with OS/2.
After you solve those problems, you can
tackle projects that aren't truly forks.
For example, we only need one editor.
Albert Cahalan wrote:
>OpenBSD should merge with NetBSD.
>XEmacs should merge with GNU Emacs.
>CinePaint should merge with The Gimp.
>Windows should merge with OS/2.
>After you solve those problems, you can
>tackle projects that aren't truly forks.
>For example, we only need one editor.
this is my last e-mail, here at linux-kernel.
Too much offtopic, sorry guys.
read my post again. are you blind?
>> But to have two proyects, same code(more or less),
>> same goal. ^^^^^^^^^
^^^^^^^^^
what is your goal? is it different from procps2?
Yes! then ok, you win. I hope to see a top with
the rainbow at background and ps playing starmeup.
Robert, are you going to implement them too }:-) ?
-thank you-
regards,
--
Software is like sex, it's better when it's bug free.
Adrian Bunk wrote:
> Disabling the proc filesystem is simple by unchecking one item in the
> kernel config menu and different from taking out "a chunk of libc" it's
> more or less supported.
It's worse: if a system is brought up for reduced operation, e.g.
with init=/bin/sh for repair work, it is not uncommon for /proc to
be absent.
Since it is not immediately obvious for a user whether a given
program depends on /proc or not, just crashing in such a situation
is clearly a case poor user interface design.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/