Xref: utzoo comp.bugs.sys5:1018 comp.unix.wizards:16965
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.bugs.sys5,comp.unix.wizards
Subject: Re: ULIMIT adjustment in System V kernel creation
Message-ID: <8709@chinet.chi.il.us>
Date: 17 Jun 89 03:34:31 GMT
References: <252@chip.UUCP> <1989Jun9.142904.1778@eci386.uucp> <32409@apple.Apple.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Followup-To: comp.bugs.sys5
Organization: Chinet - Public Access Unix
Lines: 22

In article <32409@apple.Apple.COM> ric@Apple.COM (Ric Urrutia) writes:

>Another way of doing it would be to write a c program that sets ulimit
>to some value and then exec's /etc/getty.  You could call it something
>like ungetty and pass it an argument (whatever ulimit you wanted).  Then
>you could simply replace the getty entries in /etc/inittab with the 
>name of your new program.  This seems a lot cleaner and you can set the
>ulimit to whatever you want per tty.

Unfortunately not everything that writes file is started by a getty.
For example, many things that write log entries are started directly
by init running the rc? scripts.  Other things are started by cron.
SysV should let you fix these by putting the entries in the root
crontab as "ulimit nnnn ; su -c user command ..." but that is pretty
ugly.  Even more unfortunately, many background processes inherit their
ulimit from more or less random parents.  Suppose you send mail to
another machine and your ulimit is set low.  Mail will invoke uucico
to deliver the file.  Guess what happens if the other machine has a
huge file waiting to be picked up....


Les Mikesell