How can I get _all_ arguments passed to a process with a process list
commando in Solaris?

If I have a very long argument list and a long path name to the binary
it get's too long and can't be viewed with the regular ps command
(?).
All I need to see is the pid and binary with argument list.

I've tried the following:
ps -fe
ps -A -o pid,args
/usr/ucb/ps axwww

None of the above show me the full argument list. Any ideas?

Best Regards,
Nergal

On 2007-07-02 10:06:33 +0100, nergal <nergal@nergal.se> said:

> How can I get _all_ arguments passed to a process with a process list
> commando in Solaris?
> 
> If I have a very long argument list and a long path name to the binary
> it get's too long and can't be viewed with the regular ps command
> (?).
> All I need to see is the pid and binary with argument list.
> 
> I've tried the following:
> ps -fe
> ps -A -o pid,args
> /usr/ucb/ps axwww
> 
> None of the above show me the full argument list. Any ideas?

pargs?

Cheers,

Chris

On Jul 2, 12:22 pm, Chris Ridd <chrisr...@mac.com> wrote:
> On 2007-07-02 10:06:33 +0100, nergal <ner...@nergal.se> said:
>
> > How can I get _all_ arguments passed to a process with a process list
> > commando in Solaris?
>
> > If I have a very long argument list and a long path name to the binary
> > it get's too long and can't be viewed with the regular ps command
> > (?).
> > All I need to see is the pid and binary with argument list.
>
> > I've tried the following:
> > ps -fe
> > ps -A -o pid,args
> > /usr/ucb/ps axwww
>
> > None of the above show me the full argument list. Any ideas?
>
> pargs?
>
> Cheers,
>
> Chris

right, forgot that one and it works good, thanks :)

Cheers

nergal <nergal@nergal.se> wrote:
> How can I get _all_ arguments passed to a process with a process list
> commando in Solaris?

It's not necessarily possible.

> If I have a very long argument list and a long path name to the binary
> it get's too long and can't be viewed with the regular ps command
> (?).
> All I need to see is the pid and binary with argument list.

> I've tried the following:
> ps -fe
> ps -A -o pid,args
> /usr/ucb/ps axwww

> None of the above show me the full argument list. Any ideas?

/usr/ucb/ps should work, but it needs to have privileges on that process
(usually means either the process owner or root).  

'pargs' will show you what the process thinks of as the argument list,
but it may be a lie.

Also: <http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/72d986124e8f77a/>

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Jul 2, 10:39 am, Darren Dunham <ddun...@redwood.taos.com> wrote:
> nergal <ner...@nergal.se> wrote:
> > How can I get _all_ arguments passed to a process with a process list
> > commando in Solaris?
> It's not necessarily possible.
> > If I have a very long argument list and a long path name to the binary
> > it get's too long and can't be viewed with the regular ps command
> > (?).
> > All I need to see is the pid and binary with argument list.
> > I've tried the following:
> > ps -fe
> > ps -A -o pid,args
> > /usr/ucb/ps axwww
> > None of the above show me the full argument list. Any ideas?
> /usr/ucb/ps should work, but it needs to have privileges on that process
> (usually means either the process owner or root).

You got a better ucb/ps than me. As root I only get 80 chars no matter
how many "w"'s I use : >
/usr/ucb/ps axwww|grep '^   755'|awk 'sub("   755 \?\?       S  0:00
","")1'| wc -c
80

> 'pargs' will show you what the process thinks of as the argument list,
> but it may be a lie.

Definitely can lie on the o/p of xterm for example.
aliased ps:
755 ??       S  0:00 xterm -fn 12x24 etc
pargs magically changes -fn to <NULL> (?!)
at argv[1]
755:    xterm -fn 12x24 -sl 4096 -ls -vb -bg Black -fg Ivory -cr Gold4
-ms gray -sb -na
argv[0]: xterm
argv[1]: <NULL>
argv[2]: 12x24
argv[3]: -sl
etc.

How about this:
pargs 1076
1076:   /usr/lib/sendmail -bd -q15m
argv[0]: sendmail: accepting
connections
argv[1]: <NULL>
argv[2]: nnections

Not terribly useful - could be a bug in my pargs as -l never works
either : <

gerryt <lepsysinc@gmail.com> wrote:
>> /usr/ucb/ps should work, but it needs to have privileges on that process
>> (usually means either the process owner or root).

> You got a better ucb/ps than me. As root I only get 80 chars no matter
> how many "w"'s I use : >
> /usr/ucb/ps axwww|grep '^   755'|awk 'sub("   755 \?\?       S  0:00
> ","")1'| wc -c
> 80

What OS?  It works fine on a Solaris express box I happened to be on,
but I can try it on some others.

# perl -le 'sleep 50 ; print "@ARGV"' A really long set of arguments to a perl process that exceeds 80 characters and then some &
[1] 1931
# /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 1076
> 1076:   /usr/lib/sendmail -bd -q15m
> argv[0]: sendmail: accepting
> connections
> argv[1]: <NULL>
> argv[2]: nnections

> Not terribly useful

That's why I said the information may not completely exist.

> could be a bug in my pargs as -l never works
> either : <

What do you get instead?  

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Jul 2, 2:09 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:
> gerryt <lepsys...@gmail.com> wrote:
> >> /usr/ucb/ps should work, but it needs to have privileges on that process
> >> (usually means either the process owner or root).
> > You got a better ucb/ps than me. As root I only get 80 chars no matter
> > how many "w"'s I use : >
> > /usr/ucb/ps axwww|grep '^   755'|awk 'sub("   755 \?\?       S  0:00
> > ","")1'| wc -c
> > 80
> What OS?  It works fine on a Solaris express box I happened to be on,
> 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 &
> [1] 1931
> # /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 1076
> > 1076:   /usr/lib/sendmail -bd -q15m
> > argv[0]: sendmail: accepting
> > connections
> > argv[1]: <NULL>
> > argv[2]: nnections
> > Not terribly useful
> That's why I said the information may not completely exist.

Indeed : >

> > could be a bug in my pargs as -l never works
> > either : <
> What do you get instead?

# 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.

gerryt <lepsysinc@gmail.com> wrote:
>> What OS?  It works fine on a Solaris express box I happened to be on,
>> 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.

I'm not at that level, but I get the same output that I posted earlier
on both SPARC and x86.  I've got b63 on x86/vmware and it too is the same.

>> > could be a bug in my pargs as -l never works
>> > either : <

>> What do you get instead?

> # 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've never seen that before.  

> I'd be more nervous if the x86 box behaved differently but it doesnt.
> But Im still uncomfortable.

Can you run these commands while booted from install media to
single-user mode?

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Jul 2, 5:32 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:
> gerryt <lepsys...@gmail.com> wrote:
> >> What OS?  It works fine on a Solaris express box I happened to be on,
> >> 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.
> I'm not at that level, but I get the same output that I posted earlier
> on both SPARC and x86.  I've got b63 on x86/vmware and it too is the same.
Not good news for me.
> >> > could be a bug in my pargs as -l never works
> >> > either : <
> >> What do you get instead?
> > # 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've never seen that before.

Id suspect a hack but it would have to be one clever one...

> > I'd be more nervous if the x86 box behaved differently but it doesnt.
> > But Im still uncomfortable.
> Can you run these commands while booted from install media to
> single-user mode?

Good idea. Ill try that later tonite. The suns out - its a holiday
here.
Two things that rarely coincide here - not to be passed up : >

G

On 2007-07-03 00:17:58 +0100, gerryt <lepsysinc@gmail.com> said:

> # 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.

Check out line 1181 (etc) of 
<http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ptools/pargs/pargs.c> 
to see why this text is appearing.

I think the process is just scribbling junk to its argv array, which it 
is quite at liberty to do AIUI.

Cheers,

Chris

On Jul 2, 5:32 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:
> gerryt <lepsys...@gmail.com> wrote:
> >> What OS?  It works fine on a Solaris express box I happened to be on,
> >> 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.
> I'm not at that level, but I get the same output that I posted earlier
> on both SPARC and x86.  I've got b63 on x86/vmware and it too is the same.
> >> > could be a bug in my pargs as -l never works
> >> > either : <
> >> What do you get instead?
> > # 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've never seen that before.
> > I'd be more nervous if the x86 box behaved differently but it doesnt.
> > But Im still uncomfortable.
> Can you run these commands while booted from install media to
> single-user mode?

Some commands yes. pargs -l works on a 6/06 DVD booted single user.
Not a lot of processes to test, but -l working is "interesting"..

I did a check of pargs, isaexec and the libraries called by sparcv9/
pargs
at the fingerprint database and all passed...

I tried a different shell and pared down the environment to minimal
and still
pargs -l gets that corrupted argument list error, so apparently no
environment corruption.

A basic truss says this at the end:
856/1:          fstat(2, 0xFFFFFFFF7FFFDA10)                    = 0
856/1:          write(2, " p a r g s", 5)                       = 5
856/1:          write(2, " :   t a r g e t   h a s".., 37)      = 37
856/1:          _exit(1)
Not sure where this 0xFFFFFFFF7FFFDA10 comes from. Only time its
mentioned.



> Darren Dunham                                           ddun...@taos.com
> Senior Technical Consultant         TAOS            http://www.taos.com/
> Got some Dr Pepper?                           San Francisco, CA bay area
>          < This line left intentionally blank to confuse you. >

nergal <nergal@nergal.se> writes:

>How can I get _all_ arguments passed to a process with a process list
>commando in Solaris?

>If I have a very long argument list and a long path name to the binary
>it get's too long and can't be viewed with the regular ps command
>(?).
>All I need to see is the pid and binary with argument list.

>I've tried the following:
>ps -fe
>ps -A -o pid,args
>/usr/ucb/ps axwww

>None of the above show me the full argument list. Any ideas?

pargs, perhaps?

If you do not have permission to read the process' address space you
cannot get the full argument listing.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Chris Ridd <chrisridd@mac.com> wrote:
> On 2007-07-03 00:17:58 +0100, gerryt <lepsysinc@gmail.com> said:

>> # 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.

> Check out line 1181 (etc) of 
> <http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ptools/pargs/pargs.c> 
> to see why this text is appearing.

OpenGrok problems?  I get 404 on all files at the moment....

> I think the process is just scribbling junk to its argv array, which it 
> is quite at liberty to do AIUI.

"a" process is at liberty to do that, yes.  But I don't think it's
common, certainly not for most OS processes.  He's apparently getting
this on *all* processes he checks.  That suggests to me something is
happening at a system level.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Jul 3, 9:05 am, Darren Dunham <ddun...@redwood.taos.com> wrote:
> Chris Ridd <chrisr...@mac.com> wrote:
> > On 2007-07-03 00:17:58 +0100, gerryt <lepsys...@gmail.com> said:
> >> # 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.
> > Check out line 1181 (etc) of
> > <http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/pto...>
> > to see why this text is appearing.
>
> OpenGrok problems?  I get 404 on all files at the moment....
>
> > I think the process is just scribbling junk to its argv array, which it
> > is quite at liberty to do AIUI.
> "a" process is at liberty to do that, yes.  But I don't think it's
> common, certainly not for most OS processes.  He's apparently getting
> this on *all* processes he checks.  That suggests to me something is
> happening at a system level.

Im about to do a fresh install I think. pargs is strange, ps is
strange,
patchadd is strange too. Does not explain why I see similar
results on x86 b65 tho'
All that is common by then is "bash" for a shell.
But su - to root using /bin/sh and not typing exec bash changes
nothing so i dont think its bash either.
Backup done. See you in a few hours : >

On 2007-07-03 17:05:22 +0100, Darren Dunham <ddunham@redwood.taos.com> said:

> Chris Ridd <chrisridd@mac.com> wrote:
>> On 2007-07-03 00:17:58 +0100, gerryt <lepsysinc@gmail.com> said:
> 
>>> # 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.
> 
>> Check out line 1181 (etc) of
>> <http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ptools/pargs/pargs.c>
to 
>> 
>> see why this text is appearing.
> 
> OpenGrok problems?  I get 404 on all files at the moment....

It worked just now... But I'm sure you've got your mercurial repository 
handy anyway ;-)

>> I think the process is just scribbling junk to its argv array, which it
>> is quite at liberty to do AIUI.
> 
> "a" process is at liberty to do that, yes.  But I don't think it's
> common, certainly not for most OS processes.  He's apparently getting
> this on *all* processes he checks.  That suggests to me something is
> happening at a system level.

Maybe. But there's some messing with locales and stuff in the pargs 
code, so the problem could be in Gerry's environment.

Cheers,

Chris

Chris Ridd <chrisridd@mac.com> wrote:
>> this on *all* processes he checks.  That suggests to me something is
>> happening at a system level.

> Maybe. But there's some messing with locales and stuff in the pargs 
> code, so the problem could be in Gerry's environment.

Oooo.  Locale's an excellent place to look.  I tend to forget about that
when I'm investigating.

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Jul 3, 10:42 am, Darren Dunham <ddun...@redwood.taos.com> wrote:
> Chris Ridd <chrisr...@mac.com> wrote:
> >> this on *all* processes he checks.  That suggests to me something is
> >> happening at a system level.
> > Maybe. But there's some messing with locales and stuff in the pargs
> > code, so the problem could be in Gerry's environment.
> Oooo.  Locale's an excellent place to look.
> I tend to forget about that
> when I'm investigating.

Sometimes I do too. Not this time : >
My default is always "C" on home boxes.
I also pared down the environment at one point and
couldnt narrow it down to anything there.

Anyway same env at this level as I recycled my .profile and .bashrc
from the backup. And all is well.
Im back up to u3 GA at the moment and plugging
some stuff back in and about to start a pca session.
which will bring my kernel level to -36

/usr/ucb/ps and pargs work fine at this point : >

I just got a PCI SATA card in the mail so its a busy day..

G

> Darren Dunham                                           ddun...@taos.com
> Senior Technical Consultant         TAOS            http://www.taos.com/
> Got some Dr Pepper?                           San Francisco, CA bay area
>          < This line left intentionally blank to confuse you. >

On Jul 3, 10:42 am, Darren Dunham <ddun...@redwood.taos.com> wrote:
> Chris Ridd <chrisr...@mac.com> wrote:
> >> this on *all* processes he checks.  That suggests to me something is
> >> happening at a system level.
> > Maybe. But there's some messing with locales and stuff in the pargs
> > code, so the problem could be in Gerry's environment.
> Oooo.  Locale's an excellent place to look.  I tend to forget about that
> when I'm investigating.

Ok Im back to where I was this morning.
/usr/ucb/ps axww and pargs -l
do the wrong thing again.
This time I patched everything in su mode using pca.

gerryt wrote:
> # pargs -l 1076
> pargs: target has corrupted argument list

I get the same on fully patched Solaris 10 11/06 (both SPARC and x86) 
machines, but *only* for the sendmail process:

# pargs 370
370:    /usr/lib/sendmail -Ac -q15m -L sm-msp-queue
argv[0]: sendmail: Queue runner@00:15:00 for /var/spool/clientmqueue 
 
 
 

argv[1]: <NULL>
argv[2]: @00:15:00 for /var/spool/clientmqueue 
 
 
 

argv[3]: :00 for /var/spool/clientmqueue 
 
 
 

argv[4]:  for /var/spool/clientmqueue 

# pargs -l 370
pargs: target has corrupted argument list

If it's only sendmail for you, too, I guess it's sendmail which does 
something strange with its argument list.

mp.
-- 
Systems Administrator | Institute of Scientific Computing | Univ. of Vienna
                       | http://www.par.univie.ac.at/solaris/pca/
Patch Check Advanced  | Analyze, download and install patches for Sun 
Solaris

Martin Paul <map@par.univie.ac.at> writes:

>gerryt wrote:
>> # pargs -l 1076
>> pargs: target has corrupted argument list

>I get the same on fully patched Solaris 10 11/06 (both SPARC and x86) 
>machines, but *only* for the sendmail process:

Sendmail is know for playing with the argument vector for showing
what it is doing.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On Jul 4, 3:51 am, Martin Paul <m...@par.univie.ac.at> wrote:
> gerryt wrote:
> > # pargs -l 1076
> > pargs: target has corrupted argument list
> I get the same on fully patched Solaris 10 11/06 (both SPARC and x86)
> machines, but *only* for the sendmail process:
> # pargs 370
> 370:    /usr/lib/sendmail -Ac -q15m -L sm-msp-queue
> argv[0]: sendmail: Queue runner@00:15:00 for /var/spool/clientmqueue
> argv[1]: <NULL>
> argv[2]: @00:15:00 for /var/spool/clientmqueue
> argv[3]: :00 for /var/spool/clientmqueue
> argv[4]:  for /var/spool/clientmqueue
> # pargs -l 370
> pargs: target has corrupted argument list
> If it's only sendmail for you, too, I guess it's sendmail which does
> something strange with its argument list.

I get it for "everything". every PID Ive looked at anyway.

As an aside to Martin:
All the re-install has fixed so far is patchadd -p works properly
again : >

Further checking reveals that /usr/ucb/ps axwww works SOME of the
time.
An xterm session has truncated output yet webconsole does not
Thats whether Im root or xterm user...
Inconsistent. Not good. I have a lot of services turned off. But they
should not affect
/usr/ucb/ps output...?

gerryt <lepsysinc@gmail.com> wrote:

> Ok Im back to where I was this morning.
> /usr/ucb/ps axww and pargs -l
> do the wrong thing again.
> This time I patched everything in su mode using pca.

Sounds like a bad patch?  Did it break immediately afterward?

-- 
Darren Dunham                                           ddunham@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

On Jul 5, 8:28 am, Darren Dunham <ddun...@redwood.taos.com> wrote:
> gerryt <lepsys...@gmail.com> wrote:
> > Ok Im back to where I was this morning.
> > /usr/ucb/ps axww and pargs -l
> > do the wrong thing again.
> > This time I patched everything in su mode using pca.
> Sounds like a bad patch?  Did it break immediately afterward?

Somewhere. After -36 kernel patch there were about 200 more
which went all in one pca session. : /
The current kernel patch is 125100-10
Where to begin. Not too keen on backing off kernel patches etc for
this issue
just yet.. Im hoping its a services thing or something equally
obvious : >

On Jul 5, 8:28 am, Darren Dunham <ddun...@redwood.taos.com> wrote:
> gerryt <lepsys...@gmail.com> wrote:
> > Ok Im back to where I was this morning.
> > /usr/ucb/ps axww and pargs -l
> > do the wrong thing again.
> > This time I patched everything in su mode using pca.
>
> Sounds like a bad patch?  Did it break immediately afterward?

A follow-up
I backed off to -36 and still had the same weirdness. So its not a
kernel patch.

I think you know the sequence - Install u3. kernel @ about -33
A pca run stops you after the -36 patch is applied even if you need
200 more.
You reboot reconfigure and continue the next 200 or so.
So one or more of those 200 patches breaks /usr/ucb/ps axww behaviour
in such a way that no matter how many w's you add only the first one
counts : >

BUT if you are root you get to see more info UNLESS you look at the
pid
of xterm or dtterm in a CDE environment. I see all opts of Xsun tho'.

So where to look..

> --
> Darren Dunham                                           ddun...@taos.com
> Senior Technical Consultant         TAOS            http://www.taos.com/
> Got some Dr Pepper?                           San Francisco, CA bay area
>          < This line left intentionally blank to confuse you. >