🚀 go-pugleaf

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