bernsten@phoenix.Princeton.EDU (Dan Bernstein) (04/14/89)
PROBLEM: If the total number of characters in argv and envp (including the nulls at the end of each word) is 1016 or less, and the arguments haven't been munged too much, ps(1) will report the arguments and environment. If the number is 1017 or more, ps will switch to (realprocessname) form, no matter what. MACHINES: This has been observed on an Ultrix 2.0 (variant BSD 4.2) system. REPEAT-BY: Pick a really really long terminal description from termcap, and set your TERMCAP variable to it. Try ps -gx, ps -gex, ps -gewwx, etc. If the process still shows up normally, try making your environment even longer than that. Eventually (once you've passed 1016, on this system) you'll see the ps report itself as (ps). By playing with the length and size of argv and envp, you can find the numerical limit. DISCUSSION: I know ps doesn't make any great claims as to ability to figure out the argv and envp, but 1016 is too small. The argument list has a limit of 10240, on most systems; the environment probably has the same limit, though I can't find this in the manuals. So wherever that hard-coded limit around 1016 is specified, there should be 20480 at least. At the very least, the documentation for ps should say that a long argv+envp can give you problems; I couldn't figure out why all my processes were suddenly being reported as (process) until I realized the change happened when I lengthened my TERMCAP. As I have no root access I can't analyze the problem. However, since a local process reporter (sps(1)) shows similar symptoms, the problem may lie in /dev/*mem rather than /bin/ps. ---Dan Bernstein, bernsten@phoenix.princeton.edu
guy@auspex.auspex.com (Guy Harris) (04/19/89)
> As I have no root access I can't analyze the problem. However, > since a local process reporter (sps(1)) shows similar symptoms, > the problem may lie in /dev/*mem rather than /bin/ps. Not likely. "/dev/mem" wouldn't know an argument list or environment list if it came up and bit it in the ass; it just hands you data from physical memory. However, the 4.3BSD "ps" *does* quite explicitly limit the amount of argument/environment data it'll print to CLSIZE*NBPG (i.e., one "operating system's notion of a page", or 1024 bytes) minus a couple or so longwords of other stuff, which accounts quite nicely for the 1016. "sps" probably either lifted much of the code from "ps", or works similarly to "ps", which would account for it having a similar limitation. Printing more of the argument list may or may not be a win (especially on systems such as SunOS 4.0, with a "max arg list" size of about 1 megabyte - no, that's not a typo); after a while, it'd probably be like reading the phone book. It might be nice if it could avoid getting fouled up by large environments, although it might be a bit more effort to read in more than one page of the stack.