root@gold.sub.org (Christian Seyb) (04/21/91)
Hello, I am using Unix 5.4 (4.0.2) and have a problem with ulimit. in /etc/default/login I have the following entry: ULIMIT=99999 This should give every user (also uucico and news) a very high ulimit. The problem is, that this doesn't work. The default ulimit is still 2MB for any user logging in. I also tried to change the default value of ulimit in /etc/conf/mtune - without any change to the behaviour of ulimit. For normal users the solution is easy - I just set the desired ulimit in $HOME/.profile. For programs like uucico, this is not possible. Any suggestions? regards Christian -- Christian Seyb | Internet: cs@gold.de.intel.com uucp login: nuucp Fuchsweg 86 | Mailbox: +49-8106-34593 24h 300-19200 PEP/V.32 8011 Baldham | +49-8106-34692 24h 300-19200 HST -- Wer nach allen Seiten offen ist, kann nicht ganz dicht sein.
cpcahil@virtech.uucp (Conor P. Cahill) (04/22/91)
root@gold.sub.org (Christian Seyb) writes: >I am using Unix 5.4 (4.0.2) and have a problem with ulimit. Read the FAQ posting for comp.unix.sysv386 (if you don't have a copy, send me email & I will send it to you). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
scotte@applix.com (Scott Evernden) (04/23/91)
In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: >Hello, > >I am using Unix 5.4 (4.0.2) and have a problem with ulimit. Upping your ulimit is described in the FAQ for this group. I quote: " 1. If your desired limit is > 12288(6MB): Edit /etc/conf/cf.d/mtune to change the following line: ULIMIT 3072 2048 12288 to: ULIMIT 3072 2048 xxxxx where xxxxx is the limit you desire. 2. Edit /etc/conf/cf.d/stune to add/change the following line: ULIMIT xxxxx where xxxxx is the limit you desire. Note that this step can be performed in the kernel configuration software (i.e.: kconfig for 386/ix). 3. Edit /etc/default/login to delete the ULIMIT line. 4. Rebuild the kernel and reboot. " -scott
urban@cbnewsl.att.com (john.urban) (04/23/91)
In article <1186@applix.com> scotte@applix.UUCP (Scott Evernden) writes: >In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: >>Hello, >> >>I am using Unix 5.4 (4.0.2) and have a problem with ulimit. > >Upping your ulimit is described in the FAQ for this group. I quote: " > > 1. If your desired limit is > 12288(6MB): > > Edit /etc/conf/cf.d/mtune to change the following line: > ULIMIT 3072 2048 12288 > to: > ULIMIT 3072 2048 xxxxx > > where xxxxx is the limit you desire. > > 2. Edit /etc/conf/cf.d/stune to add/change the following line: > > ULIMIT xxxxx > > where xxxxx is the limit you desire. Note that this step can > be performed in the kernel configuration software (i.e.: kconfig > for 386/ix). > > 3. Edit /etc/default/login to delete the ULIMIT line. > > 4. Rebuild the kernel and reboot. > The FAQ answer for ulimit is not correct for UNIX System V Release 4.0. In 4.0, ULIMIT has been replaced by [SH]FSZLIM. SFSZLIM - Soft File SiZe LIMit and HFSZLIM - Hard File SiZe LIMit. In the mtune file, SFSZLIM and HFSZLIM are in hex. The currect values (for UNIX System V/386 Release 4.0) are: 0x200000 -> 2097152. So therefore these "rule" above change to ... 1) If your desired limit is > 12288(6MB -> 6291456) There is no need to modify your mtune file, since the maximum file size is 0x7FFFFFFF (2147483647 bytes or 4194303 512 byte blocks) As we recall the layout in the mtune file is: Kernel Variable<TAB>Current Value<TAB>Lowest Value<TAB>Highest Value The values for SFSZLIM/HFSZLIM are: SFSZLIM 0x200000 0x100000 0x7FFFFFFF HFSZLIM 0x200000 0x100000 0x7FFFFFFF 2) Run idtune(1M) (or edit /etc/conf/cf.d/stune directly) /etc/conf/bin/idtune SFSZLIM <new value in hex> /etc/conf/bin/idtune HFSZLIM <new value in hex> e.g. to be able to make 10 Meg files ... /etc/conf/bin/idtune SFSZLIM 0xA00000 /etc/conf/bin/idtune HFSZLIM 0xA00000 3) Edit /etc/default/login to delete the ULIMIT line 4) Rebuild the kernel and reboot cd / /etc/conf/bin/idbuild && /etc/conf/bin/idreboot Sincerely, John Urban
dcm@baldur.dell.com (Dave McCracken) (04/24/91)
scotte@applix.com (Scott Evernden) writes: >In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: >>Hello, >> >>I am using Unix 5.4 (4.0.2) and have a problem with ulimit. >Upping your ulimit is described in the FAQ for this group. I quote: " > 1. If your desired limit is > 12288(6MB): > Edit /etc/conf/cf.d/mtune to change the following line: > ULIMIT 3072 2048 12288 > to: > ULIMIT 3072 2048 xxxxx > etc. Unfortunately, this is no longer accurate for Unix 5.4 (SVR4). The files that need to be changed are still valid (/etc/conf/cf.d/?(mtune|stune)), but the value that controls file size limit (nee ULIMIT) has changed. As of SVR4, the complete BSD-style resource limit capability has been implemented. To change what is commonly considered ULIMIT, you need to change the entries SFSZLIM (for soft limit) and HFSZLIM (for hard limit). They are close to the bottom of the mtune file, along with some comments (!!) that describe what they are. These limits are in bytes, rather than blocks, and a value of 0 is no longer used to mean unlimited. Unlimited is now MAXINT. Note that the ULIMIT entry in /etc/default login should still work, and the shells still understand the ulimit command. For a quick peek at the new features, to a "ulimit -A" to ksh. Unfortunately, the values are printed in blocks for compatibility, so be prepared for some confusion. -- Dave McCracken dcm@dell.dell.com (512) 343-3720 Dell Computer 9505 Arboretum Blvd Austin, TX 78759-7299
ram@attcan.UUCP (Richard Meesters) (04/24/91)
In article <1991Apr21.140740.6766@gold.sub.org>, root@gold.sub.org (Christian Seyb) writes: > I am using Unix 5.4 (4.0.2) and have a problem with ulimit. > > in /etc/default/login I have the following entry: > ULIMIT=99999 > > This should give every user (also uucico and news) a very high ulimit. > The problem is, that this doesn't work. The default ulimit is still > 2MB for any user logging in. I also tried to change the default value > of ulimit in /etc/conf/mtune - without any change to the behaviour of > ulimit. > > For normal users the solution is easy - I just set the desired ulimit > in $HOME/.profile. For programs like uucico, this is not possible. > > Any suggestions? > This may help - Info via a support newsletter. You need to tune the SFSZLIM and HFSZLIM (in /etc/conf/cf.d/stune) to set the required ulimit. These values are tuned with a hex value of the file size in bytes (eg: 0x500000 is 5MB). SFSZLIM is the soft limit specifying the largest offset in bytes of any single file that may be created by the process. HFSZLIM is the max value of SFSZLIM. You can overide this setting by using ULIMIT in /etc/default/login, but any program that is exec'd setuid (ie: uucico), then ulimit will be set back to the system wide defaults defined by SFSZLIM and HFSZLIM. Regards, ------------------------------------------------------------------------------ Richard A Meesters | Technical Support Specialist | Insert std.logo here AT&T Canada | | "Waste is a terrible thing ATTMAIL: ....attmail!rmeesters | to mind...clean up your act" UUCP: ...att!attcan!ram | ------------------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (04/25/91)
>Upping your ulimit is described in the FAQ for this group.
As S5R4's resource-limiting code is derived from 4.3BSD's to a large
degree, and as the ulimit is, I think, the same as the RLIMIT_FSIZE
limit, if you wish can you just say "ulimits suck" and set the ulimit to
RLIMIT_INFINITY, i.e. 0x7fffffff (at least in 4.3BSD and many
derivatives), and not have a ulimit *at all*?dcm@baldur.dell.com (Dave McCracken) (04/25/91)
ram@attcan.UUCP (Richard Meesters) writes: >In article <1991Apr21.140740.6766@gold.sub.org>, root@gold.sub.org (Christian Seyb) writes: >You can overide this setting by using ULIMIT in /etc/default/login, but any >program that is exec'd setuid (ie: uucico), then ulimit will be set back to >the system wide defaults defined by SFSZLIM and HFSZLIM. I had forgotten about that little bug. The exec code in SVR4 1.0 and 2.0 will reset all your resource limits to the values from stune/mtune for any setuid program. I fixed it in Dell's version a long time ago to only reset it if the current value is less than the compiled-in values. AT&T has incorporated that bug fix into Version 3.0, so it will eventually appear elsewhere. -- Dave McCracken dcm@dell.dell.com (512) 343-3720 Dell Computer 9505 Arboretum Blvd Austin, TX 78759-7299
nvk@ddsw1.MCS.COM (Norman Kohn) (04/27/91)
In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: >in /etc/default/login I have the following entry: >ULIMIT=99999 > >This should give every user (also uucico and news) a very high ulimit. >The problem is, that this doesn't work. The default ulimit is still >2MB for any user logging in. I also tried to change the default value >of ulimit in /etc/conf/mtune - without any change to the behaviour of >ulimit. > >For normal users the solution is easy - I just set the desired ulimit >in $HOME/.profile. For programs like uucico, this is not possible. > >Any suggestions? > If you can set it in $HOME/.profile, the system-wide ulimit set by /etc/login/default should (and via mtune) was recognized but a subsequent invocation set it lower... check out /etc/profile. (Moreover: what's done by $HOME/.profile can be done in /etc/profile.) -- Norman Kohn | ...ddsw1!nvk Chicago, Il. | days/ans svc: (312) 650-6840 | eves: (312) 373-0564
bdb@becker.UUCP (Bruce D. Becker) (04/28/91)
In article <dcm.672428949@baldur> dcm@baldur.dell.com (Dave McCracken) writes: |scotte@applix.com (Scott Evernden) writes: | |>In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: |>>Hello, |>> |>>I am using Unix 5.4 (4.0.2) and have a problem with ulimit. | |>Upping your ulimit is described in the FAQ for this group. I quote: " |> 1. If your desired limit is > 12288(6MB): |> Edit /etc/conf/cf.d/mtune to change the following line: |> ULIMIT 3072 2048 12288 |> to: |> ULIMIT 3072 2048 xxxxx |> etc. | |Unfortunately, this is no longer accurate for Unix 5.4 (SVR4). |The files that need to be changed are still valid |(/etc/conf/cf.d/?(mtune|stune)), but the value that controls Where will one find these files in the System V release 4 version for the Amiga? |file size limit (nee ULIMIT) has changed. As of SVR4, the complete |BSD-style resource limit capability has been implemented. To |change what is commonly considered ULIMIT, you need to change |the entries SFSZLIM (for soft limit) and HFSZLIM (for hard limit). |They are close to the bottom of the mtune file, along with some |comments (!!) that describe what they are. These limits are in |bytes, rather than blocks, and a value of 0 is no longer used |to mean unlimited. Unlimited is now MAXINT. | |Note that the ULIMIT entry in /etc/default login should still |work, and the shells still understand the ulimit command. For |a quick peek at the new features, to a "ulimit -A" to ksh. |Unfortunately, the values are printed in blocks for compatibility, |so be prepared for some confusion. That seems to be "ulimit -a" here... -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "The really important problems require greater earnestness" - J. Cage
det@nightowl.MN.ORG (Derek E. Terveer) (04/28/91)
In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: >in /etc/default/login I have the following entry: >ULIMIT=99999 > >This should give every user (also uucico and news) a very high ulimit. >The problem is, that this doesn't work. The default ulimit is still >2MB for any user logging in. I also tried to change the default value >of ulimit in /etc/conf/mtune - without any change to the behaviour of >ulimit. [Read the manual pages on mtune(4) and stune(4)] The file "mtune" contains the default values and allowable ranges for some system parameters, like ULIMIT. Use idtune(1) to change the parameters (within the range specified by "mtune") in the file "stune" and then rebuild the kernel. The new values will take affect *after* you have successfully rebuilt the kernel and rebooted; not before. You can also modify the user's ulimit in /etc/default/login -- det@nightowl.mn.org
dfields@radium.urbana.mcd.mot.com (David Fields) (04/30/91)
One thing that should be noted about the mtune and stune files is that this is not the way configuration was done on the 3b2 reference port nor is it the way it's done on the 68k or 88k reference ports. There isn't a standard way to do configuration from USL. Dave Fields // Motorola Computer Group // dfields@urbana.mcd.mot.com
peter@micromuse.co.uk (Peter Galbavy) (04/30/91)
scotte@applix.com (Scott Evernden) writes: >In article <1991Apr21.140740.6766@gold.sub.org> root@gold.sub.org (Christian Seyb) writes: >>Hello, >> >>I am using Unix 5.4 (4.0.2) and have a problem with ulimit. >Upping your ulimit is described in the FAQ for this group. I quote: " [stuff deleted] >-scott This is for V.3.2 etc only. There is some sort of problem with V.4 that stops you increasing the default ulimit in the kernel, and can on be set using ulimit() or in the /etc/default/login (etc) files. Can somebody who knows if this is a real bug, and whether there is a work around for it (V4 !) please post... -- Peter Galbavy Tech Support, Micromuse Ltd Phone: +44 71 352 7774 E-Mail: P.Galbavy@micromuse.co.uk Disclaimer: Time flies like an arrow... Fruit flies like a banana
woods@eci386.uucp (Greg A. Woods) (05/03/91)
In article <2544@urbana.mcd.mot.com> dfields@urbana.mcd.mot.com writes: > One thing that should be noted about the mtune and stune files is > that this is not the way configuration was done on the 3b2 reference port > nor is it the way it's done on the 68k or 88k reference ports. > There isn't a standard way to do configuration from USL. Just to be picky.... since the 3b2 reference port is the first version, and the one originally from AT&T, this should be considered the standard against which one compares features. Are the mc68k and mc88k versions different from the 3b2 version in the way they configure and tune the kernel? If so, *WHY*?!?!? Are they differenet in other ways, particularly w.r.t. administration? If so, *WHY*?!?!?!? I'd be very wary of using the i386 version(s) for any sort of comparison. They are the only versions that will contain some specific levels of compatibility to XENIX, such as the ability to run Intel OMF binaries. Certainly SysV/386 r3.2 was quite different in having more than just XENIX binary compatibility.... The bad vibes continue! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
dfields@radium.urbana.mcd.mot.com (David Fields) (05/07/91)
The reference m88k and m68k configuration is very similar to the reference 3b2. Of course any vendor can change these however they feel as there isn't an standard as yet. There is also great incentive to change this as it's not a simple interface. The 3b2 reference port may have been first but all that means is that there were more bugs. The i386 port is the only one I'd base a product on. Dave Fields // Motorola Computer Group // dfields@urbana.mcd.mot.com <Nobody pays any attention to disclaimers anyway.>
woods@eci386.uucp (Greg A. Woods) (05/09/91)
In article <2550@urbana.mcd.mot.com> dfields@urbana.mcd.mot.com writes: > The reference m88k and m68k configuration is very similar to the reference > 3b2. Good. I would hope so! Certainly drivers are going to be different, but it's the same O/S, with the same tunable parameters (outside any required by specific drivers). > Of course any vendor can change these however they feel as there > isn't an standard as yet. There is also great incentive to change this > as it's not a simple interface. There should be *great* incentive for every vendor not to change anything at the user/administrator level at all! The entire O/S is a standard, as specified by the reference ports from UI. Any vendor who attempts to claim otherwise and provide their own "custom" "enhancements" brings serious doubt to their commitment. If there's something wrong with the interface to kernel configuration, then it's going to be wrong on every version, and should be changed in the reference port, perhaps through some form of feedback and consensus from the various vendors. Certainly it should be UI's responsibility to facilitate this. Just why do you think it's not simple anyway? I presume it's tied into FACE for those who don't/can't read the manual and do it the "real" way. > The 3b2 reference port may have been first but all that means is that > there were more bugs. The i386 port is the only one I'd base a > product on. Scary that you should say that. Actually I've heard the 3b2 port runs quite well. I'd run it on my 3b2 if I could get it for < $7,000(US)! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
bdb@becker.UUCP (Bruce D. Becker) (05/10/91)
In article <1991May8.183914.3059@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: |In article <2550@urbana.mcd.mot.com> dfields@urbana.mcd.mot.com writes: |> The reference m88k and m68k configuration is very similar to the reference |> 3b2. | |Good. I would hope so! Certainly drivers are going to be different, |but it's the same O/S, with the same tunable parameters (outside any |required by specific drivers). | |> The 3b2 reference port may have been first but all that means is that |> there were more bugs. The i386 port is the only one I'd base a |> product on. | |Scary that you should say that. Actually I've heard the 3b2 port runs |quite well. I'd run it on my 3b2 if I could get it for < $7,000(US)! Apparently the m68k port to the Commodore Amiga is in good shape - it certainly doesn't cost > $7000(US), even if you include all the hardware... -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.
dfields@radium.urbana.mcd.mot.com (David Fields) (05/10/91)
In article <1991May8.183914.3059@eci386.uucp>, woods@eci386.uucp (Greg A. Woods) writes: >In article <2550@urbana.mcd.mot.com> dfields@urbana.mcd.mot.com writes: <text deleted> >> Of course any vendor can change these however they feel as there >> isn't an standard as yet. There is also great incentive to change this >> as it's not a simple interface. > >There should be *great* incentive for every vendor not to change >anything at the user/administrator level at all! The entire O/S is a >standard, as specified by the reference ports from UI. Any vendor who >attempts to claim otherwise and provide their own "custom" >"enhancements" brings serious doubt to their commitment. < more text deleted > I agree in principal but the reality is that while UI is working on this it isn't finished and people need to ship usable products now. The administration interface has traditionaly been an are that many vendors have changed to be more suitable to the percieved needs of their customer base. <the "it" below refers to kernel configuration> >Just why do you think it's not simple anyway? I presume it's tied >into FACE for those who don't/can't read the manual and do it the >"real" way. You presume wrong. >Scary that you should say that. Actually I've heard the 3b2 port runs >quite well. I'd run it on my 3b2 if I could get it for < $7,000(US)! Two points here the reference port from USL is not the AT&T product and "runs quite well" is a relative term associated with how you use a system. The same system which may be stable with 3 users in a a software development environment may be very unstable with 30 users using a database. Let me point out that I haven't used a 3b2 reference port very much, I've just seen the number of changes from the last 3b2 port to the latest 386 reference from USL. Dave
wes@harem.clydeunix.com (Barnacle Wes) (05/18/91)
In article <1991May8.183914.3059@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > Scary that you should say that. Actually I've heard the 3b2 port runs > quite well. I'd run it on my 3b2 if I could get it for < $7,000(US)! In article <99416@becker.UUCP>, bdb@becker.UUCP (Bruce D. Becker) writes: % Apparently the m68k port to the Commodore % Amiga is in good shape - it certainly doesn't % cost > $7000(US), even if you include all % the hardware... That depends on your definition of "Good Shape." I played with an Amiga 3000/UX at the local dealer a month ago, and I found it to be excruciatingly slow, compared to myth, my brother's Step 386/20 with ISC Unix. The speed was comparable to obie, my Sperry PC/IT 7.16 Mhz 286 with Microport V/AT. This is a giant step backwards, I think. I guess Commodore should've waited for the 4000/UX ('040 machine). Wes Peters -- #include <std/disclaimer.h> The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes
bdb@becker.UUCP (Bruce D. Becker) (05/21/91)
In article <289@harem.clydeunix.com> wes@harem.clydeunix.com (Barnacle Wes) writes: | |In article <99416@becker.UUCP>, bdb@becker.UUCP (Bruce D. Becker) writes: |% Apparently the m68k port to the Commodore |% Amiga is in good shape - it certainly doesn't |% cost > $7000(US), even if you include all |% the hardware... | |That depends on your definition of "Good Shape." I played with an |Amiga 3000/UX at the local dealer a month ago, and I found it to be |excruciatingly slow, compared to myth, my brother's Step 386/20 with |ISC Unix. The speed was comparable to obie, my Sperry PC/IT 7.16 Mhz |286 with Microport V/AT. This is a giant step backwards, I think. I |guess Commodore should've waited for the 4000/UX ('040 machine). Hmmm, you must have been playing with the X/Openlook stuff, which isn't currently in Good Shape due to being a too-vanilla port of X11R3, sigh. Fixed in Amiga Unix 2.0, or so I hear. Other than that, unless your dealer was showing some older demo version, I'd be surprised if any 386 system could come near the performance of the A3000 system (no need for the 68040 add-in card to do it either 8^). -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.