mparker@chip.UUCP (M. D. Parker) (06/09/89)
Under the current System V R3 flavor of operating system I am using, our ULIMIT is gened up to max value. In otherwords, there is no restriction. While I like that approach, I do want to limit the value locally since we have had an occaion where one person ran us out of user disk space. My preference is to change this in the kernel. Initial examinations of what I have received do not point to which parameter to change. Anybody know? Yes, I do know that I could put a wrapper around /etc/init to do this but I'd really like to at least know about the kernel modification. Thanks for your help.
clewis@eci386.uucp (Chris Lewis) (06/09/89)
In article <252@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >Under the current System V R3 flavor of operating system I am using, >our ULIMIT is gened up to max value. Oh you lucky sod! This is how it *should* be - makes everything else so simple... >In otherwords, there is no restriction. >While I like that approach, I do want to limit the value locally since we >have had an occaion where one person ran us out of user disk space. My >preference is to change this in the kernel. Initial examinations of what >I have received do not point to which parameter to change. Anybody know? >Yes, I do know that I could put a wrapper around /etc/init to do this but >I'd really like to at least know about the kernel modification. Remember that you can adjust the ulimit *down* without root privilege... Put in your /etc/profile: if [ $LOGNAME = <users you wish to restrict> ] then ulimit <whatever you wish - as long as it's *downwards*> fi Or, get fancy and do something like: ul=`sed -n -e '/^$LOGNAME[ <tab>]/s/^.*[ <tab>][ <tab>]*//p' /etc/ulimitsperuser` if [ -n "$ul" ] then ulimit $ul fi [/etc/ulimitsperuser consists of tab separated username, ulimit value pairs, one pair per line] remember: - the user's shell runs /etc/profile and any shell settings/ ulimit etc persist for that user. - *any* user can lower ulimit for themselves, but only root can raise it [Aside: it's too bad in a way that the shell you get doesn't run effective id == 0 during execution of /etc/profile, and undoes this just before executing your personal profile - would make upping ulimit or other similar things easy to do on a per-user basis, though it would require some co-operation from /etc/login and probably an explicit shell builtin to change the effective userid back to the real] -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/09/89)
In article <252@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >While I like that approach, I do want to limit the value locally since we >have had an occaion where one person ran us out of user disk space. Set ulimit by a command in /etc/profile.
john@wa3wbu.UUCP (John Gayman) (06/11/89)
In article <252@chip.UUCP>, mparker@chip.UUCP (M. D. Parker) writes: > Under the current System V R3 flavor of operating system I am using, > our ULIMIT is gened up to max value. In otherwords, there is no restriction. In the case of Microport V/386 the kernel is directly patchable to whatever ULIMIT you like. I looked through the linkkit and couldn't find any references to ulimit so perhaps "patch" is the only way. In any event, a "patch" program comes with the distribution and you simply invoke it with: /etc/patch /unix Ulimit xxxx (where xxxx is the number of blocks) You then simply reboot and you have the new limit. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
ric@Apple.COM (Ric Urrutia) (06/14/89)
In article <1989Jun9.142904.1778@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >In article <252@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >>Under the current System V R3 flavor of operating system I am using, >>our ULIMIT is gened up to max value. > >Oh you lucky sod! This is how it *should* be - makes everything else >so simple... > > >Remember that you can adjust the ulimit *down* without root privilege... > >Put in your /etc/profile: > >if [ $LOGNAME = <users you wish to restrict> ] >then > ulimit <whatever you wish - as long as it's *downwards*> >fi > >Or, get fancy and do something like: > > ul=`sed -n -e '/^$LOGNAME[ <tab>]/s/^.*[ <tab>][ <tab>]*//p' > /etc/ulimitsperuser` > if [ -n "$ul" ] > then > ulimit $ul > fi >[/etc/ulimitsperuser consists of tab separated username, ulimit value >pairs, one pair per line] > >remember: > - the user's shell runs /etc/profile and any shell settings/ > ulimit etc persist for that user. > - *any* user can lower ulimit for themselves, but only root can > raise it > >[Aside: it's too bad in a way that the shell you get doesn't run effective >id == 0 during execution of /etc/profile, and undoes this just before >executing your personal profile - would make upping ulimit or other similar >things easy to do on a per-user basis, though it would require some >co-operation from /etc/login and probably an explicit shell builtin to change >the effective userid back to the real] >-- >Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. >UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis >Phone: (416)-595-5425 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.
fongd@csusac.uucp (Dick Fong) (06/14/89)
I didn't have a need or desire to work with system v until
recently (used vax and suns mainly).. and still I don't have
a desire to do so.. the question I have is what is the purpose
of ulimit?? it's really doesn't limit a user to the space
s/he uses.. it just makes it very annoying.. the user
just ends up with a lot of 1 meg (or what every the ulimit is
set to) files..
well.. unfortunately, we didn't have source to our kernel..
but we did make two patches to our kernel..
the first one was to take out the check in the ulimit to
see if the user was root.. thereby making it possible for
ANY user to up their ulimit.. the second was to make the
initial ulimit to be 16 megs.. 16 megs (0x7fff) is the max
you can set without some severe kernel hacks.. the first
patch isn't all that simple but it wasn't hard, the second
one is quite easy.. (a total of 4 bytes were changed for both
patches) for patch two:
all you need to do is read out 'main' from the kernel (with
the help from 'nm' and simple program that seeks to a location
in a file and read out a certain amount of bytes and write
out what it finds to a file) and look for where the default
value is loaded (with either 'hd' or 'od').. (we were lucky
that our 'main' in our kernel only had one 0x0800.. which was our
default ulimit...) and find the bytes surrounding it..
after you know what you are looking for, write a simple program
that will look for that certain byte sequence and change it in
your kernel. the one thing you should make sure of is that you
only find ONE occurance of this byte sequence (i.e. you don't make
this change to something else in the kernel.. it would
most likely be bad...) when we did this, we were quite
paranoid of the actual bytes we changed.. so our program
we wrote double checked the locations where we made the
changes.. after that, reboot and the ulimit should be changed..
either that or you've mangled your kernel..
as I said, I'm not sure if this works for anything else
besides a 3b15 running release 2.x.. and even then.. I
won't say it will work on your system, but our system is
running much happier now..
I've heard rumor that the ulimit value will be a kernel
variable in some later release.. which makes life much
easier if you want to change it..
--
----------------------------------------------------------------------
Dick Fong <*:*> UUCP: {ucdavis|lll-crg}!csusac!fongd
Internet: fongd@csusac.csus.educlewis@eci386.uucp (Chris Lewis) (06/16/89)
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. But then you have to change the semantics of the /etc/inittab line, perform argument parsing etc. What'll you break? (tty line administration utilities like ISC sysadm). What happens if you make a mistake like putting non-numeric characters in the inittab entry (you *might* not be able to log in again...) Why bother? Stock SV getty doesn't even provide an opportunity to set TERM! REMEMBER: getty doesn't know who you are. Getty is an ideal place for line-specific initializations (TERM), but not user-specific. [Ie: why would you want to set ulimit on a per-line basis?] It seems to be that the correct way to limit file size is during /etc/profile. (because user initializations are what it is for...) And that the correct default ulimit is infinity (or as near to it as you can get...). If your system has a low default, make it (almost) infinity by moving /etc/getty to /etc/realgetty, and compile the following and install as /etc/getty: main(argc, argv) int arc; char **argv; { ulimit(2, 0x7fffffff); execv("/etc/realgetty", argv); } Then one line of shell script in your /etc/profile plus a per-user list can tune ulimit to anything you want. Actually, the getty thing should be done to init instead so that all processes get the higher ulimit. However, making a mistake can have somewhat greater consequences.... -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
les@chinet.chi.il.us (Leslie Mikesell) (07/22/89)
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
pim@ctisbv.UUCP (Pim Zandbergen) (07/23/89)
In article <1989Jun16.165538.27038@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: >In article <32409@apple.Apple.COM> ric@Apple.COM (Ric Urrutia) writes: > >And that the correct default ulimit is infinity (or as near to it as you >can get...). > [ description of a wrapper to set ULIMIT to 2147483647 (2^31 -1) deleted ] DON'T set your ulimit to anything higher then 2143289343 (2^31 - 2^22 - 1) if you are running System V release 3, or you will have problems with cpio(1). When restoring from a tape with, cpio will fail to write a file if the size of a file exceeds the ulimit. There is, however a bug in cpio, where it will not write any files if the ulimit is higher then 2143289343. It will fail with the message: file skipped: exceeds ulimit by n bytes where "file" is the name of the file to be written, and n = (2^31 - ulimit) * 512 + size, where "ulimit" is the current ulimit, and "size" is the size of the file to be written. As a special case, n = -(2^31) + size, if ulimit = 2143289344 (2^31 - 2^22) This bug is present in cpio in System V release 3.1.1 on the AT&T 3B2/600. I don't know if it is in any other SysVr3's. Can anybody with a source license comment on this ? -- --------------------+----------------------+----------------------------------- Pim Zandbergen | phone: +31 70 542302 | CTI Software BV pim@ctisbv.UUCP | fax : +31 70 512837 | Laan Copes van Cattenburch 70 ...!uunet!mcvax!hp4nl!ctisbv!pim | 2585 GD The Hague, The Netherlands