Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: ji@corto.inria.fr (John Ioannidis - Altair)
Newsgroups: comp.sys.sun
Subject: Re: in.rshd problems
Message-ID: <1235@inria.UUCP>
Date: 22 Feb 89 11:58:46 GMT
References: <526@alice.marlow.uucp>
Sender: usenet@rice.edu
Organization: GIP-Altair (IN2|INRIA|LRI)
Lines: 30
Approved: Sun-Spots@rice.edu
Original-Date: 10 Feb 89 15:43:20 GMT
X-Sun-Spots-Digest: Volume 7, Issue 164, message 6 of 9
X-Issue-Reference: v7n139

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