pete@tsc.UUCP (Pete Schmitt) (11/12/87)
Does anyone know how to raise the ulimit on a 3b2?
--
\\\!/// From: Pete Schmitt
_ _ UUCP: allegra!decwrl!tsc.dec.com!pete
( Q Q ) DECnet: tsc::pete
---,,,,-------U-------,,,,--- It's okay to say the U... word.pete@tsc.UUCP (Pete Schmitt) (11/12/87)
In article <226@tsc.UUCP>, pete@tsc.UUCP (Pete Schmitt) writes: > > Does anyone know how to raise the ulimit on a 3b2? I also meant to say that the OS is SYSV 3.1. -- \\\!/// From: Pete Schmitt _ _ UUCP: allegra!decwrl!tsc.dec.com!pete ( Q Q ) DECnet: tsc::pete ---,,,,-------U-------,,,,--- It's okay to say the U... word.
heiby@mcdchg.UUCP (11/16/87)
You say that you are running SVR3.1 on your 3B2. In SVR3.1 ulimit is (FINALLY!!!!) a tunable parameter. Check your Admin Guide on changing tunable parameters for details. Basically, on a 3B2, it involved modifying /etc/master.d/kernel, as I recall. Have fun! -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Intel architectures build character."
ronald@csuchico.EDU (Ronald Cole) (11/22/87)
In article <226@tsc.UUCP> pete@tsc.UUCP (Pete Schmitt) writes: >Does anyone know how to raise the ulimit on a 3b2? I had to do this on a 3B5 to make news more managable without root's intervention and some crontab verbiosity. If you have System V Release 2 and the source code, change the CDLIMIT define in param.h from 1L<<11 (the 1 meg limit) to 1L<<12 (2 meg; 13 = 4 meg... etc.); then recompile the kernel. This should have been a tunable parameter, hacking it otherwise is ugly and leaves a bad taste on my unix palate! I'm not sure if this works with Release 3, we haven't gotten our 3B5 to 3B15 migration yet. -- Ronald Cole | uucp: ihnp4!csun!csuchico!ronald AT&T 3B5 System Manager | PhoneNet: ronald@csuchico.edu California State University, Chico | voice (916) 895-4635 "... and if you don't like it, you must lump it." -Joseph Smith
karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) (11/25/87)
#!/bin/sh
#
# ulimit.hack: Create an intermediate program for use in
# between kernel initialization and init startup.
# Stare at this script a while, then run it.
#
# Caveat: Heaven help you if you screw this up. This puts
# a new program in as /etc/init, which then execs the real init.
#
cat > ulimit.init.c << \EOF
main(argc, argv)
int argc;
char *argv[];
{
ulimit(2, 262144L); /* "2" is the "set" command. */
/* 262,144 allows for 128Mb files to be written. */
/* If that value isn't suitable, roll your own. */
execv("/etc/real.init", argv);
}
EOF
#
# Compile it and put it in place of the usual init program.
#
cc ulimit.init.c -o ulimit.init
mv /etc/init /etc/real.init
mv ulimit.init /etc/ulimit.init
ln /etc/ulimit.init /etc/init
mv ulimit.init.c /etc/ulimit.init.c # to keep src for this hack nearby.
chmod 0754 /etc/init
exit 0
#
# Upon system reboot, all processes will inherit the new large ulimit.
-=-
Karlrobby@eiibank.UUCP (11/26/87)
In article <2280@tut.cis.ohio-state.edu> karl@tut.cis.ohio-state.edu writes: [script to mess with init setting ulimit before exec-ing the real init] ># Upon system reboot, all processes will inherit the new large ulimit. >-=- >Karl My impression is that what is being discussed is the variable ULIMIT which is the maximum write size of a file. If so, then DO NOT mess with init. In SYS V version 2.something and later ULIMIT is a TUNABLE parameter. Go to /etc/master.d and look at the file called kernel. In the last half of the file you will see a line that looks something like ULIMIT 2048 The number is the setting of ULIMIT. What you do is the following: change the value in kernel to be what you want. Then go to /boot. Type mkboot -k KERNEL this sets up the bootable objects to include the new kernel parameters. The go to firmware and execute the program /etc/system from the disk your / is on. When you come up, you will have a new /unix with ULIMIT set to what you want. NOTE: THIS IS NOT A HACK. This is what the AT&T Manuals say you should do to set the ULIMIT. Also, it works without a hitch. We have two 3b2400s and both of them have ULIMIT set to 8meg using this method of tuning. In fact, this method is what you do to tune any of the tunable parameters (max processes/user, various system table sizes, etc.). -Robby -- Robby Kates ...ihnp4!eiibank!robby Beatrice Corporate Headquarters, Chicago "...and a lover who looks straaaaangly, like Time the Avenga..." -CH- #include <disclaimer.h>
karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) (11/30/87)
robby@eiibank.UUCP writes:
My impression is that what is being discussed is the variable
ULIMIT which is the maximum write size of a file. If so, then DO
NOT mess with init. In SYS V version 2.something and later ULIMIT
is a TUNABLE parameter.
The max-file-size-limit is exactly what that script is supposed to
fix. In fact, that limit did not become a tunable until (*cringe*)
SysV.3.1; I have a SysV.3.0 3B2/400 called osu-cis which does not have
any reference to ULIMIT in its /etc/master.d/kernel.
The script I posted is something I wrote 2 years ago when fighting
this problem every time I turned around (I am in the habit of having
to move very large files around with quite some frequency), and I
formalized it for myself and also sent it to Richard Stallman for
inclusion in the standard GNU Emacs distribution when I was doing SysV
compatibility things for that program; I picked up the copy I posted
here from just such a distribution. Although it is quite tunable in
The Right Way via /etc/master.d files in V.3.1, it took AT&T
altogether TOO LONG to figure this out, and in fact it was ridiculous
of them to have ever imposed the stupid 1Mb limit in the first place.
So if you have V.3.1, please ignore the script I posted. If, however,
you are one of the vast, VAST majority of non-AT&T sites (and thus
cannot get V.3.1 practically for free) running V.3.0 or V.2.x.y.z.a.b,
then that script will do a very nice job of "fixing" your ulimit
problems.
-=-
Karljph@houxa.UUCP (12/01/87)
In article <2445@tut.cis.ohio-state.edu>, karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) writes: >> robby@eiibank.UUCP writes: >> My impression is that what is being discussed is the variable >> ULIMIT which is the maximum write size of a file. If so, then DO >> NOT mess with init. In SYS V version 2.something and later ULIMIT >> is a TUNABLE parameter. > > The max-file-size-limit is exactly what that script is supposed to > fix. In fact, that limit did not become a tunable until (*cringe*) > SysV.3.1; I have a SysV.3.0 3B2/400 called osu-cis which does not have > any reference to ULIMIT in its /etc/master.d/kernel. > > The script I posted is something I wrote 2 years ago when fighting > this problem every time I turned around (I am in the habit of having > to move very large files around with quite some frequency), and I > formalized it for myself and also sent it to Richard Stallman for > inclusion in the standard GNU Emacs distribution when I was doing SysV > compatibility things for that program; I picked up the copy I posted > here from just such a distribution. Although it is quite tunable in > The Right Way via /etc/master.d files in V.3.1, it took AT&T > altogether TOO LONG to figure this out, and in fact it was ridiculous > of them to have ever imposed the stupid 1Mb limit in the first place. > > So if you have V.3.1, please ignore the script I posted. If, however, > you are one of the vast, VAST majority of non-AT&T sites (and thus > cannot get V.3.1 practically for free) running V.3.0 or V.2.x.y.z.a.b, > then that script will do a very nice job of "fixing" your ulimit > problems. > -=- > Karl A much safer and more selective way to accomplish the same result is to replace references to getty to references to a program similiar to the one Karl proposed. The program should set ULIMIT to a higher value, and then exec the real getty. Simply use the new program in place of getty ONLY ON THE PORTS THAT NEED THE HIGHER ULIMIT (such as for uucp/news). I seem to remember a program distributed by AT&T a few years ago to 3B users (unlimit.c I think) that did the same thing. ------- Disclaimer: I hereby disclaim all my debts. ------ Jack Harkins @ AT&T Bell Labs Princeton Information (201) 949-3618 (201) 357-7573 ihnp4!houxa!jph
karl@mumble.cis.ohio-state.edu (Karl Kleinpaste) (12/02/87)
jph@houxa.UUCP writes:
A much safer and more selective way to accomplish the same result
is to replace references to getty to references to a program
similiar to the one Karl proposed. The program should set ULIMIT
to a higher value, and then exec the real getty. Simply use the
new program in place of getty ONLY ON THE PORTS THAT NEED THE
HIGHER ULIMIT (such as for uucp/news).
No, this will not have the same result at all. How long is your cron
log, or your sulog? How long do your news logfiles get? How long do
you let your <whatever-other-logfile> get? Replacing getty will only
catch things that happen via people (or machines) logging in; it will
not catch automatic, cron-initiated things.
Do it right, at the source, in init. Consider that the tunability of
the ulimit is now (in V.3.1 and later) even farther back, in the REAL
source, the kernel itself. Now, if you want to mess with restricted
ulimits for normal users, do it in the right place, which I consider
to be /etc/profile. Joe Random User can be forced to execute "ulimit
2048" there if you really want to impose a 1Mb limit on him.
-=-
Karl