maximum length of process command stored in unix
championsleeper
stored in the process control block structure on the various flavours
of unix. i've noticed that for long commands even with the -e option
on hp-ux 11i you do not get the full binary listing. i've managed to
get more using the UNIX95=ps ... syntax but really want to know:
a. what is the maximum character length stored per o/s,
b. what are the best native commands e.g. ps, UNIX95 to use to access
the maximum data available and,
c. are there any advantages of accessing process information through
native libaries aviaialble in c, c++, perl on these systems.
Logan Shaw
> can anyone inform me on the maximum length of a command which is
> stored in the process control block structure on the various flavours
> of unix. i've noticed that for long commands even with the -e option
> on hp-ux 11i you do not get the full binary listing. i've managed to
> get more using the UNIX95=ps ... syntax but really want to know:
> a. what is the maximum character length stored per o/s,
In Solaris, I believe the length of argument list that the kernel
stores is 80 characters. (PRARGSZ is defined as 80 in
/usr/include/sys/procfs.h.) I believe that 80 characters includes
the null terminator for the string.
If I understand correctly, the reason there is a limit like this
even though one can have a longer command line is that the argument
list is stored in the process's (user-space) memory, and it's
problematic for tools like "ps" to have to go rooting through
a process's memory to determine its argument list. (For one
thing, what if the process changes the memory -- either on purpose
or accidentally -- so that the data structure is no longer valid?)
For that reason, when a command is executed (i.e. when exec()
is called), a truncated version of the argument list is copied
into kernel data structures. It's probably limited to 80
characters to make it easier to manage and to avoid wasting
space.
> b. what are the best native commands e.g. ps, UNIX95 to use to access
> the maximum data available and,
On Solaris, /usr/bin/ps works well enough to get at that. If
you wish to get just the argument list for process 12345, you can
do something like
ps -p 12345 -o args
You can also use /usr/ucb/ps to get at more of the argument
list. I believe this goes through the same process of rooting
around in the process's address space, though, so it isn't
without its problems.
> c. are there any advantages of accessing process information through
> native libaries aviaialble in c, c++, perl on these systems.
The obvious thing to do on Solaris is probably to use /proc.
/usr/include/sys/procfs.h defines data structures you can use
to read /proc/NNNN/psinfo to get that information.
The only other thing you could do is execute /usr/ucb/ps directly,
but I'm not sure if /usr/ucb/ps is always necessary installed
on the system. It might be part of an option package. If so,
relying on it would not be a good idea.
- Logan
Dale Ghent
> The only other thing you could do is execute /usr/ucb/ps directly,
> but I'm not sure if /usr/ucb/ps is always necessary installed
> on the system. It might be part of an option package. If so,
> relying on it would not be a good idea.
FWIW, you'll need the SUNWscpu and SUNWscpux packages installed for
/usr/ucb/ps and friends.
/dale
Rich Teer
> The only other thing you could do is execute /usr/ucb/ps directly,
> but I'm not sure if /usr/ucb/ps is always necessary installed
> on the system. It might be part of an option package. If so,
> relying on it would not be a good idea.
The preferred method from Solaris 9 is to use pargs (no, I didn't
set root's prompt!):
[root@sedm1323] /> pargs 723
723: /usr/lib/saf/ttymon -g -h -p sedm1323 console login: -T sun -d /dev/console -l
argv[0]: /usr/lib/saf/ttymon
argv[1]: -g
argv[2]: -h
argv[3]: -p
argv[4]: sedm1323 console login:
argv[5]: -T
argv[6]: sun
argv[7]: -d
argv[8]: /dev/console
argv[9]: -l
argv[10]: console
argv[11]: -m
argv[12]: ldterm,ttcompat
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Kamal R. Prasad
> championsleeper wrote:
> > can anyone inform me on the maximum length of a command which is
> > stored in the process control block structure on the various flavours
> > of unix. i've noticed that for long commands even with the -e option
> > on hp-ux 11i you do not get the full binary listing. i've managed to
> > get more using the UNIX95=ps ... syntax but really want to know:
> > a. what is the maximum character length stored per o/s,
>
> In Solaris, I believe the length of argument list that the kernel
> stores is 80 characters. (PRARGSZ is defined as 80 in
> /usr/include/sys/procfs.h.) I believe that 80 characters includes
> the null terminator for the string.
>
> If I understand correctly, the reason there is a limit like this
> even though one can have a longer command line is that the argument
> list is stored in the process's (user-space) memory, and it's
> problematic for tools like "ps" to have to go rooting through
> a process's memory to determine its argument list. (For one
> thing, what if the process changes the memory -- either on purpose
> or accidentally -- so that the data structure is no longer valid?)
>
> For that reason, when a command is executed (i.e. when exec()
> is called), a truncated version of the argument list is copied
> into kernel data structures. It's probably limited to 80
> characters to make it easier to manage and to avoid wasting
> space.
>
copied from userspace to kernel in a buffer of size 2048 bytes and not
80 bytes. struct proc -may or may not truncate the p_comm(or cmdline)
to less than LINE_MAX(2048 bytes).
> > b. what are the best native commands e.g. ps, UNIX95 to use to access
> > the maximum data available and,
depending on how buggy /proc is (or is not), I would use /proc.
If you want to do it programmatically, use getprocs() which is called
by ps.
regards
-kamal
Kamal R. Prasad
>
[snip]
> c. are there any advantages of accessing process information through
> native libaries aviaialble in c, c++, perl on these systems.
getprocs() is a system call that returns process table entries. Use it
from any language and its equally efficient.
regards
-kamal
Logan Shaw
> depending on how buggy /proc is (or is not), I would use /proc.
> If you want to do it programmatically, use getprocs() which is called
> by ps.
There is no manual page for "getprocs" on my Solaris 8 system. What
flavor(s) of Unix does this system/library call exist on?
- Logan
Casper H.S. Dik
>When you execute a command, execve() syscall results in cmdline being
>copied from userspace to kernel in a buffer of size 2048 bytes and not
>80 bytes. struct proc -may or may not truncate the p_comm(or cmdline)
>to less than LINE_MAX(2048 bytes).
2 Megabyte, not 2K.
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.
eponymo...@yahoo.com
> championsleeper wrote:
> > can anyone inform me on the maximum length of a command which is
> > stored in the process control block structure on the various
>
> In Solaris, I believe the length of argument list that the kernel
> stores is 80 characters. (PRARGSZ is defined as 80 in
> /usr/include/sys/procfs.h.) I believe that 80 characters includes
> the null terminator for the string.
>
> is called), a truncated version of the argument list is copied
> into kernel data structures. It's probably limited to 80
> characters to make it easier to manage and to avoid wasting
> space.
In our experience, 80 characters is just not enough for practical use
in identifying processes. 256 would have been a better choice, if you
have to have a fixed upper limit. We often poke around looking for
whether or not particular processes in our systems are running. We
end up having to use /usr/ucb/ps because it's the only clean way to
accurately identify each process. Unfortunately, it's also much less
efficient because it peeks into each process's address space. Here's
a vote for extending the 80 characters to 256 or so in some future
release of Solaris.
Glenn
ba...@smaalders.net
way to accurately identify each process."?
This doesn't completely identify the process, it
merely reports the current value of the argv list
in the process address space; the process of
course may have altered it in order to hide.
- Bart
Kamal R. Prasad
Its there on AIX (I read and replied on comp.unix.aix) and some *bsd
systems.
You should be able to find the syscall used by ps on solaris. Check
out the src code at www.opensolaris.org.
regards
-kamal
eponymo...@yahoo.com
Yes, I know that; I'm assuming cooperative processes that
aren't trying to hide. This is our own application, after all.
We often start many instances of a given program, passing
them approprate configuration and instance-number options.
I mean "clean" in that the distinguishing arguments for
particular instances of our processes may well not appear
within the first 80 characters. Sometimes the reason is
a very long pathname to the binary, which eats up a lot of
the available string length. Sometimes there are simply
argument ordering constraints we have to obey. Either way,
/bin/ps doesn't cut it for us, though I wish it did because
of its superior speed.
I'm well aware that processes can be tracked by other means
(like having a persistent parent that knows the PIDs of its
children). But our environment involves many remote machines
and we don't want to depend on such persistence. And sometimes
we have multiple levels of scripting involved, so it's not like
there's just one centralized parent of everyone. Consequently,
we look to make contemporaneous probes of what's running, using
the various OS tools.
Glenn