mcneild@mcneild.Software.Mitel.COM (Doug McNeil) (11/01/90)
I've been trying unsuccessfully to build a kernel with a larger ULIMIT default kernel under Interactive 2.2. I use _idtune_ to change the ULIMIT to value within the limits, but when I build the kernel and reboot the default ULIMIT hasn't changed from its old default (4096). I've successfully increase ULIMIT on previous version of Interactive 386/ix...does anyone have any ideas? Thanks Please mail replies to: ...uunet!mitel!spock!mcneild -- -----------------------------------------------------------------------------> "Smokin" Doug McNeil | doug_mcneil@mitel.com Mitel Corporation, Kanata, Ontario | (613)592-2122 "I know a lot of fancy dancers.." - Cat Stevens |
cpcahil@virtech.uucp (Conor P. Cahill) (11/01/90)
In article <MCNEILD.90Oct31180231@mcneild.Software.Mitel.COM> mcneild@mcneild.Software.Mitel.COM (Doug McNeil) writes: > [problem of setting ulimit for ISC UNIX 2.2 deleted] READ THE FAQ POSTING for this newsgroup. If you don't got one, wait a day and you will get it (I will be posting it tonight). PS. Look at /etc/default/login -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
rad@genco.bungi.com (Bob Daniel) (11/07/90)
In article <MCNEILD.90Oct31180231@mcneild.Software.Mitel.COM> mcneild@mcneild.Software.Mitel.COM (Doug McNeil) writes: >I've been trying unsuccessfully to build a kernel with a larger >ULIMIT default kernel under Interactive 2.2. I use _idtune_ to change >the ULIMIT to value within the limits, but when I build the kernel and >reboot the default ULIMIT hasn't changed from its old default (4096). >I've successfully increase ULIMIT on previous version of Interactive >386/ix...does anyone have any ideas? For AT&T, you also need to edit /etc/default/login and add ULIMIT=xxxxx. This will change the default ULIMIT for all logins.
cpcahil@virtech.uucp (Conor P. Cahill) (11/08/90)
In article <113@genco.bungi.com> rad@genco.bungi.com (Bob Daniel) writes: >For AT&T, you also need to edit /etc/default/login and add ULIMIT=xxxxx. >This will change the default ULIMIT for all logins. Actually you should configure the kernel to have the correct ULIMIT and delete the ULIMIT line in /etc/default/login. That way you only have to remember to change one location when you need to up the ULIMIT again. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
richard@pegasus.com (Richard Foulk) (11/08/90)
>>For AT&T, you also need to edit /etc/default/login and add ULIMIT=xxxxx. >>This will change the default ULIMIT for all logins. > >Actually you should configure the kernel to have the correct ULIMIT and >delete the ULIMIT line in /etc/default/login. That way you only have >to remember to change one location when you need to up the ULIMIT >again. Or set the ULIMIT way high in the kernel and make adjustments in /etc/default/login. That way you don't need to re-link the kernel to make a change. -- Richard Foulk richard@pegasus.com
cpcahil@virtech.uucp (Conor P. Cahill) (11/09/90)
In article <1990Nov8.152741.1581@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >Or set the ULIMIT way high in the kernel and make adjustments in >/etc/default/login. That way you don't need to re-link the kernel >to make a change. This would be much better if the capability to set the ulimit on a per-user basis existed and all process starting jobs (login, cron, init) used that value when initiating a job for a particular user. The other problem with setting it in login to be different from the kernel setting is that depending upon how the job got executed, the ulimit will be different (if it got executed from cron it would have the kernel ulimit unless cron was restarted since the boot). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
jdeitch@jadpc.cts.com (Jim Deitch) (11/10/90)
In article <1990Nov09.120821.4975@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <1990Nov8.152741.1581@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >>Or set the ULIMIT way high in the kernel and make adjustments in >>/etc/default/login. That way you don't need to re-link the kernel >>to make a change. > >This would be much better if the capability to set the ulimit on a per-user >basis existed and all process starting jobs (login, cron, init) used that >value when initiating a job for a particular user. If you put a line in the .profile to LOWER the ulimit it will. Correct? As I remember, a user can lower their ulimit but not raise it. >-- >Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., >uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 > Sterling, VA 22170 -- UUCP: nosc!jadpc!jdeitch ARPA: jadpc!jdeitch@nosc.mil INET: jdeitch@jadpc.cts.com
cpcahil@virtech.uucp (Conor P. Cahill) (11/11/90)
In article <1990Nov10.034318.602@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: >>This would be much better if the capability to set the ulimit on a per-user >>basis existed and all process starting jobs (login, cron, init) used that >>value when initiating a job for a particular user. > >If you put a line in the .profile to LOWER the ulimit it will. Note that I said all processes starting jobs, not just the shell. Only the sh (or ksh, if you have it) read a .profile. Even then, the user can change it if it is in their .profile. If it is in the /etc/profile file then the same value applies to all users unless you put in some additional smarts to handle it on a per-user basis. > As I remember, a user can lower their ulimit but not raise it. This is true, but that doesn't mean that the lower ulimit will apply for jobs submited for execution by at or cron. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
richard@pegasus.com (Richard Foulk) (11/11/90)
>> As I remember, a user can lower their ulimit but not raise it. > >This is true, but that doesn't mean that the lower ulimit will apply >for jobs submited for execution by at or cron. Yes, "at" does enforce the prevailing ulimit. -- Richard Foulk richard@pegasus.com
james@bigtex.cactus.org (James Van Artsdalen) (11/12/90)
In <1990Nov11.141858.2474@pegasus.com>, richard@pegasus.com (Richard Foulk) wrote: ] As I remember, a user can lower their ulimit but not raise it. | This is true, but that doesn't mean that the lower ulimit will apply | for jobs submited for execution by at or cron. > Yes, "at" does enforce the prevailing ulimit. I suspect one could change this in /usr/lib/cron/.proto. Mine contains #ident "@(#).proto 2.3 - 88/05/26" cd $d ulimit $l umask $m $< -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789