Re: Looking for comments on a new utility...
Julian Elischer <[EMAIL PROTECTED]> writes: > we need to extend this to handle a full thread table per process.. > anyone have any ideas on how to do this? Unfortunately, I think we're going to end up reimplementing procfs in the sysctl tree... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Cyrille Lefevre wrote: > On Tue, Jun 11, 2002 at 05:15:17AM -0700, Juli Mallett wrote: ... > > would like to see done to ps(1) :) The most notable request was for a > > feature I've missed having in our ps(1) for a while, the ability to get a > > tree of processes printed so you can tell who is whose child, etc. Yes, I still missed that one. Go for it. > how about this one ? > > 1 ?0 \_ init > 2814 ttyp00 \_ sh > 2816 ttyp00 | \_ sh > 57423 ?0 | \_ sleep > 2596 ?0 \_ inetd > 24834 ?0 | \_ rlogind > 24838 ttyp00 | | \_ ksh > 24912 ttyp00 | | \_ ksh > 57504 ?0 | \_ telnetd > ^^ command tree > standard ps fields > taken from ast-open `ps -T'. Also nice (why no UID field ?) I use ps trees like these to quickly find out who is misusing what ;-) > for fun, how about a simple awk script like the one in attachment ;^) :) Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, Jun 11, 2002 at 05:15:17AM -0700, Juli Mallett wrote:
> Hej,
>
> As some of you may have noticed, I've done some poking of ps(1) lately, and
> this has brought attention of people who have ideas for things that they
> would like to see done to ps(1) :) The most notable request was for a
> feature I've missed having in our ps(1) for a while, the ability to get a
> tree of processes printed so you can tell who is whose child, etc.
>
> ps(1)'s internals, however, didn't seem quite right to me, but after about
> 10 minutes reading kvm(3) manpages and recalling some tricks with recursive
> programming to produce an N-level tree with as many as N-1 elements, I had
> come up with a simple utility to print out a "process tree".
>
> You can find the code here:
> http://people.freebsd.org/~jmallett/.proctree/proctree.c
>
> And some example output from a cluster machine here:
> http://people.freebsd.org/~jmallett/.proctree/proctree.out
> Lots of people have given feedback that they don't care much for the \_
> formatting of the tree, and I'm willing to look at patches that provide
> noticably more readable output.
how about this one ?
1 ?0 \_ init
2814 ttyp00 \_ sh
2816 ttyp00 | \_ sh
57423 ?0 | \_ sleep
2596 ?0 \_ inetd
24834 ?0 | \_ rlogind
24838 ttyp00 | | \_ ksh
24912 ttyp00 | | \_ ksh
57504 ?0 | \_ telnetd
^^ command tree
standard ps fields
taken from ast-open `ps -T'. see http://www.research.att.com/~gsf/download/tgz/
for details (maybe one I'll will finish this !@#$%^&* port which is still
broken in some way ?)
for fun, how about a simple awk script like the one in attachment ;^)
Cyrille.
--
Cyrille Lefevre mailto:[EMAIL PROTECTED]
#!/bin/sh
# was ps -ef
ps axwo "user pid ppid start tt time command" |
awk '
BEGIN {
getline
}
{
if (! nchild[$3])
nchild[$3] = 0
father[$2] = $3
children[$3, nchild[$3]] = $2
nchild[$3] ++
start[$2] = $4
tty[$2] = $5
time[$2] = $6
cmd[$2] = $7
for (i = 8; i <= NF; i++)
cmd[$2] = cmd[$2] " " $i
}
function print_parents(pid) {
if (pid != 1)
prefix = " " print_parents(father[pid])
else
prefix = " "
printf "%6i %6i %7s %s %s %s\\_ %s\n", \
pid, father[pid], start[pid], tty[pid], time[pid], \
substr(prefix, 1, length(prefix)-2), cmd[pid]
return " " prefix
}
function print_children (pid, prefix, child) {
printf "%6i %6i %7s %s %s %s\\_ %s\n", \
pid, father[pid], start[pid], tty[pid], time[pid], \
substr(prefix, 1, length(prefix)-2), cmd[pid]
if (! nchild[pid])
return
for (child = 0; child < nchild[pid] - 1; child ++)
print_children(children[pid, child], prefix " | ")
print_children(children[pid, child], prefix "")
}
END {
if (! whichpid)
whichpid = 1
if (! cmd[whichpid])
exit
if (father[whichpid])
prefix = " " print_parents(father[whichpid])
else
prefix = " "
print_children(whichpid, prefix)
}' whichpid=$1
Re: Looking for comments on a new utility...
we need to extend this to handle a full thread table per process.. anyone have any ideas on how to do this? Anyone rewriting ps should think about this twist... On 11 Jun 2002, Dag-Erling Smorgrav wrote: > Juli Mallett <[EMAIL PROTECTED]> writes: > > I believe I can get pid, ppid, username (or at least uid [yay > > user_from_uid]), etc., from sysctl(3) at least as easily as with > > kvm(3). > > You can get the full process table from sysctl (kern.proc.all) > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Juli Mallett wrote: > > Piping commands through other commands seems icky? > > Relying on reasonable output from ps(1) seems icky when you can extract the > data yourself and not have to worry about formatting getting in the way of > processing data properly. This is just wrong on so many levels... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Juli Mallett wrote:
> > |-omniNames---omniNames---3*[omniNames]
>
> That seems frighteningly useless to me though. Seems a bit like a number of
> utilities I've seen from the Linux camp which take useful functionality and
> mask it behind something that looks good. What exactly can you get from
> that kind of output?
>
> > with the following being printed if you ask for pids ('-p'):
> >
> > |-omniNames(313)---omniNames(335)-+-omniNames(336)
> > | |-omniNames(338)
> > | `-omniNames(345)
>
> That output's pretty useful, on the other hand, but it seems overly difficult
> to do that sort of formatting without kludging everything with a lot of
> conditionals and rather than simple recursion, something more complex.
Theres a program in -ports.
If you insist on doing it, though, look at the output of
"w -d" (yeah, I have a vested interest in it, but it's still
pretty cool).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, 11 Jun 2002 07:29:56 MST, Juli Mallett wrote: > > I don't think you should worry too much about _not_ getting > > reasonable output from POSIX-conformant utilities. :-) > > I'd read SUS's ps(1) escription a little closer. Very few guarantees > with it. My POSIX.2 (1993) suggests that you can get a sufficient level of regularity out of ps(1) to provide reliable input for a tree printer. I think the "5.23.6.1 Standard Output" section defines the impact of the format specified with the -o option "well enough". I haven't looked at what SUS has to say about the issue, but if it's more ambiguous, then it's a regression from POSIX.2 (1993) and should be corrected. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
* Sheldon Hearn <[EMAIL PROTECTED]> escriurères > > > On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote: > > > > Piping commands through other commands seems icky? > > > > Relying on reasonable output from ps(1) seems icky when you can extract the > > data yourself and not have to worry about formatting getting in the way of > > processing data properly. > > I don't think you should worry too much about _not_ getting reasonable > output from POSIX-conformant utilities. :-) I'd read SUS's ps(1) escription a little closer. Very few guarantees with it. > I didn't want to be the one to break the "pstree exists" news, because I > know how frustrating it is to discover that you've just engineered a > solution to a solved problem, but it's an unfortunate fact of life. I > was very annoyed when I realized that my waitpid(1) program that I was > so proud of already existed in several incarnations. :-) It's fine :) > Still, you can be proud of the work you've done. You could even get it > into the ports tree. It's always nice to have choices. That's something to think about :) Thanks. -- Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Juli Mallett <[EMAIL PROTECTED]> writes: > I believe I can get pid, ppid, username (or at least uid [yay > user_from_uid]), etc., from sysctl(3) at least as easily as with > kvm(3). You can get the full process table from sysctl (kern.proc.all) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote: > > Piping commands through other commands seems icky? > > Relying on reasonable output from ps(1) seems icky when you can extract the > data yourself and not have to worry about formatting getting in the way of > processing data properly. I don't think you should worry too much about _not_ getting reasonable output from POSIX-conformant utilities. :-) I didn't want to be the one to break the "pstree exists" news, because I know how frustrating it is to discover that you've just engineered a solution to a solved problem, but it's an unfortunate fact of life. I was very annoyed when I realized that my waitpid(1) program that I was so proud of already existed in several incarnations. :-) Still, you can be proud of the work you've done. You could even get it into the ports tree. It's always nice to have choices. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
* Andrew Kenneth Milton <[EMAIL PROTECTED]> escriurères > +---[ Juli Mallett ]-- > | > | Wasn't really aware of that existing, but my understanding from another message > | in this thread is it just works with the output from ps(1)? That seems a bit > | icky to me. > > Piping commands through other commands seems icky? Relying on reasonable output from ps(1) seems icky when you can extract the data yourself and not have to worry about formatting getting in the way of processing data properly. -- Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Le 2002-06-11, Juli Mallett écrivait : > mask it behind something that looks good. What exactly can you get from > that kind of output? The overall organization of the tree. Useless if the information you are looking for is 'what is the PID of the father of X', but may be useful when you have some complex activity going on and want to grasp the overall structure of running processes. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
+---[ Juli Mallett ]-- | | Wasn't really aware of that existing, but my understanding from another message | in this thread is it just works with the output from ps(1)? That seems a bit | icky to me. Piping commands through other commands seems icky? -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
* Sheldon Hearn <[EMAIL PROTECTED]> escriurères > On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote: > > > > As some of you may have noticed, I've done some poking of ps(1) lately, and > > this has brought attention of people who have ideas for things that they > > would like to see done to ps(1) :) The most notable request was for a > > feature I've missed having in our ps(1) for a while, the ability to get a > > tree of processes printed so you can tell who is whose child, etc. > > Like pstree in the ports tree? Wasn't really aware of that existing, but my understanding from another message in this thread is it just works with the output from ps(1)? That seems a bit icky to me. -- Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> escriurères > Juli Mallett <[EMAIL PROTECTED]> writes: > > ps(1)'s internals, however, didn't seem quite right to me, but after about > > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > > programming to produce an N-level tree with as many as N-1 elements, I had > > come up with a simple utility to print out a "process tree". > > Don't do anything in ps(1) that depends on libkvm. It has to be > doable with sysctl as well. I believe I can get pid, ppid, username (or at least uid [yay user_from_uid]), etc., from sysctl(3) at least as easily as with kvm(3). -- Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
* Thomas Quinot <[EMAIL PROTECTED]> escriurères
> Le 2002-06-11, Juli Mallett écrivait :
>
> > feature I've missed having in our ps(1) for a while, the ability to get a
> > tree of processes printed so you can tell who is whose child, etc.
>
> Yes, this would be an invaluable feature!
>
> Even nicer would be a user interface (command line, output style)
> consistent with the existing Linux pstree utility. This one also has
> a nice functionality: by default it will collapse all siblings with
> the same name, in order to limit display clutter, eg:
>
> |-omniNames---omniNames---3*[omniNames]
That seems frighteningly useless to me though. Seems a bit like a number of
utilities I've seen from the Linux camp which take useful functionality and
mask it behind something that looks good. What exactly can you get from
that kind of output?
> with the following being printed if you ask for pids ('-p'):
>
> |-omniNames(313)---omniNames(335)-+-omniNames(336)
> | |-omniNames(338)
> | `-omniNames(345)
That output's pretty useful, on the other hand, but it seems overly difficult
to do that sort of formatting without kludging everything with a lot of
conditionals and rather than simple recursion, something more complex.
> (note: this is not the same as our sysutils/pstree port, which
> postprocesses the output of ps(1)).
Yuck.
> One version of the Linux pstree is available from the psmisc port.
> Another, more recent, has been ported to several platforms (including
> NetBSD), see http://www.chiark.greenend.org.uk/~bjharris/.
Interesting. Thanks for the pointers.
--
Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve
Perception is prejudice / Don't classify me / Accept me as me / Not what you see
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Peter Edwards <[EMAIL PROTECTED]> writes: > Isn't the kvm_*() interface somewhat frowned upon? Is there anything > missing from /proc that you need kvm_* for? /proc is also frowned upon, use sysctl. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote: > > As some of you may have noticed, I've done some poking of ps(1) lately, and > this has brought attention of people who have ideas for things that they > would like to see done to ps(1) :) The most notable request was for a > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. Like pstree in the ports tree? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Juli Mallett <[EMAIL PROTECTED]> writes: > ps(1)'s internals, however, didn't seem quite right to me, but after about > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > programming to produce an N-level tree with as many as N-1 elements, I had > come up with a simple utility to print out a "process tree". Don't do anything in ps(1) that depends on libkvm. It has to be doable with sysctl as well. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Le 2002-06-11, Juli Mallett écrivait :
> feature I've missed having in our ps(1) for a while, the ability to get a
> tree of processes printed so you can tell who is whose child, etc.
Yes, this would be an invaluable feature!
Even nicer would be a user interface (command line, output style)
consistent with the existing Linux pstree utility. This one also has
a nice functionality: by default it will collapse all siblings with
the same name, in order to limit display clutter, eg:
|-omniNames---omniNames---3*[omniNames]
with the following being printed if you ask for pids ('-p'):
|-omniNames(313)---omniNames(335)-+-omniNames(336)
| |-omniNames(338)
| `-omniNames(345)
(note: this is not the same as our sysutils/pstree port, which
postprocesses the output of ps(1)).
One version of the Linux pstree is available from the psmisc port.
Another, more recent, has been ported to several platforms (including
NetBSD), see http://www.chiark.greenend.org.uk/~bjharris/.
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
Solaris has something similar in /usr/proc/bin/ptree. One of the things it lets you do is specify _which_ user to use. Isn't the kvm_*() interface somewhat frowned upon? Is there anything missing from /proc that you need kvm_* for? -- Cheers, Peter. Juli Mallett wrote: > Hej, > > As some of you may have noticed, I've done some poking of ps(1) lately, and > this has brought attention of people who have ideas for things that they > would like to see done to ps(1) :) The most notable request was for a > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. > > ps(1)'s internals, however, didn't seem quite right to me, but after about > 10 minutes reading kvm(3) manpages and recalling some tricks with recursive > programming to produce an N-level tree with as many as N-1 elements, I had > come up with a simple utility to print out a "process tree". > > You can find the code here: > http://people.freebsd.org/~jmallett/.proctree/proctree.c > > And some example output from a cluster machine here: > http://people.freebsd.org/~jmallett/.proctree/proctree.out > > Lots of people have given feedback that they don't care much for the \_ > formatting of the tree, and I'm willing to look at patches that provide > noticably more readable output. > > I'd actually like to hear what information otherwise could better be > included along with associated login, pid, cpu, etc. > > And I'd really like to hear thoughts about inclusion of this into the tree. > Does anyone hold the opinion that it absolutely cannot be included? Does > anyone have any suggestions to make the code better? > > I'm asking you guys, the CURRENT userbase, since you are users who obviously > seem to take more of an interest in FreeBSD's future, etc. :) > > Thanks, > juli. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Looking for comments on a new utility...
Hej, As some of you may have noticed, I've done some poking of ps(1) lately, and this has brought attention of people who have ideas for things that they would like to see done to ps(1) :) The most notable request was for a feature I've missed having in our ps(1) for a while, the ability to get a tree of processes printed so you can tell who is whose child, etc. ps(1)'s internals, however, didn't seem quite right to me, but after about 10 minutes reading kvm(3) manpages and recalling some tricks with recursive programming to produce an N-level tree with as many as N-1 elements, I had come up with a simple utility to print out a "process tree". You can find the code here: http://people.freebsd.org/~jmallett/.proctree/proctree.c And some example output from a cluster machine here: http://people.freebsd.org/~jmallett/.proctree/proctree.out Lots of people have given feedback that they don't care much for the \_ formatting of the tree, and I'm willing to look at patches that provide noticably more readable output. I'd actually like to hear what information otherwise could better be included along with associated login, pid, cpu, etc. And I'd really like to hear thoughts about inclusion of this into the tree. Does anyone hold the opinion that it absolutely cannot be included? Does anyone have any suggestions to make the code better? I'm asking you guys, the CURRENT userbase, since you are users who obviously seem to take more of an interest in FreeBSD's future, etc. :) Thanks, juli. -- Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve Perception is prejudice / Don't classify me / Accept me as me / Not what you see To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
