fox@uunet.uu.net (Paul Fox) (02/08/89)
We're running X11 rel 3 on our Suns now. One of the guys here decided to
use 'rsh server xterm' to get better performance on his 3/50 (avoid so
much swapping, etc). Seemed reasonable to me, until we ran out of swap
space, and I shouted at him. When I looked to see why we ran out of swap
space it was due to the in.rshd process, and not the cshells or xterms.
Doing a size /usr/etc/in.* shows that most of the in.* are pretty
reasonable sizes, (8K text + 8K data + 10-50K bss). in.rshd has the same
except, its bss is 1MB !! It doesnt take many of these to run out of swap
space.
The question is why is in.rshd SO LARGE. My feelings are that someones got
a table in the code with one or two too many 0's on the end of an array
specifier.
Any clues anyone ? Oh yeah, this is on Sun OS 4.0.1.
Tel: +44 628 891313 x. 212
UUCP: fox@marlow.uucpschwartz@shire.cs.psu.edu (Scott Schwartz) (02/11/89)
Paul Fox mcvax!marlow!fox@uunet asks: >The question is why is in.rshd SO LARGE. My feelings are that someones got >a table in the code with one or two too many 0's on the end of an array >specifier. >Any clues anyone ? Oh yeah, this is on Sun OS 4.0.1. It seems that rshd allocates an array big enough to hold the maximum number of bytes that a process can take in its argument list, and reads the incoming command into it. This number is NCARGS, found in <sys/param.h>, and is 20480 in 4.3BSD, and 0x100000 in SunOS 4.0. (Even though csh doesn't use the new higher limit :-( ) The memory problem mentioned in the original article is an interesting and probably avoidable side effect of an innocuous and otherwise beneficial change that Sun made. Just speculating, now, but I suppose people inside Sun either have lots of memory on their machines, or they don't open many NeWS/X windows on remote machines :-) :-) :-) By the way, as long as your remote command is something like Xterm, you should invoke it in the background with standard input, output and error redirected, so that rshd will exit and not hang around at all. i.e. rsh shire "xterm -display gondor:0 </dev/null >&/dev/null &" -- Scott Schwartz <schwartz@shire.cs.psu.edu> [[ Declaring a static area for the arguments? That's bad. Seems that it would be very much worth the little extra time to allocate the space as needed. Or perhaps a mixture of the two: declare a reasonably sized static area and only allocate more if you need it. By the way: I have seen people locally use "rsh" merely to start an interactive login to another host, as in simply "rsh titan". This is a good reason to use "rlogin" for these cases instead. --wnl ]]
dupuy@cs.columbia.edu (Alexander Dupuy) (02/14/89)
I don't know why in.rshd is so large, but you can eliminate it from being a problem by running remote xterms like this: csh% rsh server -n "xterm >&/dev/null &" I wasn't able to get this to work right with ksh for whatever reason. After starting up the remote xterm, the in.rshd will exit, and stop taking up swap space. You could redirect output from the xterm to a file if you didn't want to lose it. @alex
VIJAY@ITIVAX.BITNET (02/19/89)
>I have >seen people locally use "rsh" merely to start an interactive login to >another host, as in simply "rsh titan". This is a good reason to use >"rlogin" for these cases instead. --wnl Question: I have host names defined as links to rsh. My users frequently invoke remote sessions by just typing the host name. Does this mean that they are also just using gargantuan rsh to start remote sessions? [[ No, ignore that. It was wrong. "rsh" the client sees that there is no command and just exec's "rlogin" the client. "rlogin" the client contacts "rlogind" the server. The program that requires all the bss is "rshd", the server, which never enters into this picture. --wnl ]]
ji@corto.inria.fr (John Ioannidis - Altair) (02/22/89)
In article <526@alice.marlow.uucp> mcvax!marlow!fox@uunet.uu.net (Paul Fox) writes: >Doing a size /usr/etc/in.* shows that most of the in.* are pretty >reasonable sizes, (8K text + 8K data + 10-50K bss). in.rshd has the same >except, its bss is 1MB !! It doesnt take many of these to run out of swap >space.... The size of the NCARGS parameter in <sys/param.h> was increased from 10K in previous releases to 1M. (NCARGS is the absolute max # of characters in the exec arglist). Since in.rshd has to read in a line and execute it, it must reserve that much space in its bss segment so that it can read the longest possible line (in fact it reserves NCARGS+1). (size in.rshd reports a bss size of less than 1M because the initialized data don't use up the entire page of the data segment.) If you still want to change in.rshd, and don't have sources, you can try reducing the size of the bss segment in the header of the in.rshd executable using your favorite binary editor (I use gnuemacs!). It should work, but I haven't tried it. Hope all this helps, /ji #include <appropriate disclaimers> In-Real-Life: John Ioannidis E-Mail-To: <ji@cs.columbia.edu> (preferred), or <ji@walkuere.altair.fr> P-Mail-To: GIP-Altair, Dom de Voluceau BP105, Rocquencourt 78153 Le Chesnay, FR V-Mail-To: +33 1 39635227, +33 1 39635417