marc@tekig1.UUCP (Marc Frajola) (11/11/83)
For those of you who have experienced problems with parenthesized arguments on a "w" list or a "ps" list, I think that I have a solution. One day, I started asking about why cer- tain people's arguments were always parenthesized on our local vax, and I went to the point of going through someone's account really trying to find out why, but I couldn't seem to find any- thing suspicious. About a week later, the guy whose account I went through called me, and told me that all he had done was unset his EXINIT variable, and his arguments in a "ps" list were no longer gar- baged! It appears that a long EXINIT variable screws something up, and causes the system to choke when trying to locate argu- ments to processes. Why a long environment variable does this, I don't know, but it is the only thing which has been a sure-fire thing around here to clear up the problem. It could be something else, but I believe that it is the length of the variable that is causing the problem. If anyone out there in net.land can find out more about the problem, and maybe how to fix UNIX so that this never happens, I would really appreciate hearing about it. Marc Frajola, Tektronix, Beaverton, OR UUCP: ..!tektronix!tekig!tekig1!marc
philipl@azure.UUCP (Philip Lantz) (11/12/83)
Ps has a fixed size buffer into which it reads the command arguments (including the environment, which is pushed onto the stack before the arguments). The size is CLSIZE*NBPG (defined in /usr/include/sys/- param.h, 1024 on our VAX) bytes. Ps doesn't know where the beginning of the argument list is, so it starts at the end of the list and works backwards until it finds the beginning of the argument list. If it reaches the beginning of its buffer before it finds the beginning of the arguments, it gives up and just puts the command name (known by the system) in parentheses. So it is the total length of the argument list and environment which determines what ps will do. One common long environment variable is TERMCAP. I have taken to just setting this to the name of the file containing the termcap entry, instead of to the entry itself. (As documented in termcap(3)). Note that this is NOT an operating system problem; it is in ps. If you don't like it, you can fix you own version of ps that will keep reading blocks until it finds the beginning of the list. (On systems that do not need ps to be setuid, that is.) Philip Lantz tekmdp!philipl
keithp@azure.UUCP (Keith Packard) (11/14/83)
This is in reply to the author that had problems with ps giving command names in parenthesis when a long environment variable was set. The reason for this occurance is that ps looks backwards in the user stack segment for the argument list, the top-most stuff is the environment and then comes the argument list (see exec(2)). Ps only looks a little way into the user segment to keep it running at a reasonable speed. If an extremely long environment variable is in the stack, ps will not look far enough down the stack to find the arguments. Not finding those arguments, ps prints out the command name in parenthesis to indicate this. Of course, this only relates to PDP11 unixes and things that have similar exec formats (vaxen...) -keith packard tektronix!tekmdp!keithp
archiel@teklds.UUCP (Archie Lachner) (11/30/83)
I am told that if the total length of the environment, i.e., the combined lengths of ALL the environment variables, is greater than 1K bytes, then ps gives command names in parentheses rather than command line images. By removing the EXINIT environment variable, the environment is probably reduced to a level below this threshold. I suggest trying the following to check this out in particular cases: printenv | wc -c If the result is more than 1K, then the above explaination applies.