Re: Long process list
- From: gerryt <lepsysinc@xxxxxxxxx>
- Date: Mon, 02 Jul 2007 16:17:58 -0700
On Jul 2, 2:09 pm, Darren Dunham <ddun...@xxxxxxxxxxxxxxxx> wrote:
gerryt <lepsys...@xxxxxxxxx> wrote:
What OS? It works fine on a Solaris express box I happened to be on,/usr/ucb/ps should work, but it needs to have privileges on that processYou got a better ucb/ps than me. As root I only get 80 chars no matter
(usually means either the process owner or root).
how many "w"'s I use : >
/usr/ucb/ps axwww|grep '^ 755'|awk 'sub(" 755 \?\? S 0:00
","")1'| wc -c
but I can try it on some others.
SPARC u3 patched to the nines and x86 Express b65
At first I wondered if the box was suspect but on a totally different
arch I get the same...
I am not comfortable with the diffs between our systems
and Id like to sort this out.
Been getting some odd results from patchadd -p as well recently.
characters and then s# perl -le 'sleep 50 ; print "@ARGV"' A really long set of arguments to a perl process that exceeds 80 ome &
# /usr/ucb/ps xww | grep perl
1931 pts/1 S 0:00 perl -le sleep 50 ; print "@ARGV" A really long set of arguments to a perl process that exceeds 80 characters and then some
1933 pts/1 S 0:00 grep perl
pargs 1076That's why I said the information may not completely exist.
1076: /usr/lib/sendmail -bd -q15m
argv: sendmail: accepting
Not terribly useful
Indeed : >
could be a bug in my pargs as -l never worksWhat do you get instead?
either : <
# pargs -l 1076
pargs: target has corrupted argument list
Both systems as root or otherwise.
a truss of the process seems ok at first glance.
I'd be more nervous if the x86 box behaved differently but it doesnt.
But Im still uncomfortable.
- Prev by Date: Re: X server
- Next by Date: Re: controller numbering
- Previous by thread: Re: Long process list
- Next by thread: Re: Long process list