🚀 go-pugleaf

In article <697@occrsh.ATT.COM> rjd@occrsh.UUCP (Randy_Davis) writes:
->In article <16463@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
->|No - since UNIX forks init directly out of the kernel as root, why
->|not step in there and raise the ulimit before the real init gets to
->|run?
->|
->|Now you only have one wrapper instead of all the getty, login, cron,
->|and what-else-have-you versions.
->
->  Wrong - all of these schemes to change the ulimit BEFORE the login program
->is run from the normal sequence init-getty-login-shell will not work!!!
->
->  If the ulimit is set to some high number before login is run (and, in fact it
->IS), such as in the kernel, and if you are running a System V version before the
->ulimit was settable in the /etc/master.d/kernel file, the ulimit for logins is
->last set in the /bin/login program.  So, setting your kernel, your init, or
->your getty ulimit higher would be fine, yet as soon as a person logs in and
->run this (pre-3.0) /bin/login, the line "ulimit(2,<low number>);" (near line
->248 in the source if you are curious) would be implemented for all non-root
->logins, and you are back to where you started.

Curious. I don't have the sources but I have to believe you do. I can
assure you that on this Sys V.2.2 ulimit is NOT set by login and that
the init hack does work (I have been running it for years).


-- 
Ian Dall     life (n). A sexually transmitted disease which afflicts
                       some people more severely than others.