kevin@msa3b.UUCP (Kevin P. Kleinfelter) (11/27/90)
I'm running an AT&T 3B2/700.
I set ULIMIT=20480 in /etc/master.d/kernel. I then "/etc/mkboot -k kernel".
When I reboot and enter "ulimit", I still have 2048.
What am I missing?
--
Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347
{emory,gatech}!nanovx!msa3b!kevin
Soon to become {emory,gatech}!nanovx!dbses0!kevin (But not yet!)rad@genco.bungi.com (Bob Daniel) (11/29/90)
In article <1454@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >I'm running an AT&T 3B2/700. >I set ULIMIT=20480 in /etc/master.d/kernel. I then "/etc/mkboot -k kernel". >When I reboot and enter "ulimit", I still have 2048. >What am I missing? >-- Do you mean '/etc/mkboot -k KERNEL'? I think it has to be in CAPS. Also, I do a 'touch /etc/system' before rebooting. What version of UNIX is this?
kevin@cfctech.cfc.com (Kevin Darcy) (12/08/90)
In article <140@genco.bungi.com> rad@genco.bungi.com (Bob Daniel) writes: >In article <1454@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >>I'm running an AT&T 3B2/700. >>I set ULIMIT=20480 in /etc/master.d/kernel. I then "/etc/mkboot -k kernel". >>When I reboot and enter "ulimit", I still have 2048. >>What am I missing? >>-- > >Do you mean '/etc/mkboot -k KERNEL'? I think it has to be in CAPS.... Well, I assume Kevin didn't get an error from mkboot when he ran it, so he probably just typed it lowercase in his posting. Alternatively, he might have a source/kernel-object license, and there was a valid kernel.o in his pwd (??) > Also, >I do a 'touch /etc/system' before rebooting. Right. That was going to be my suggestion. No config changes will ever take effect on a 3B2 (at least the r3 600's, 700's and 1000's that I've used) unless and until you go through a "self-config" reboot, either by a) Changing the EDT by adding/removing hardware (assuming the hardware isn't EXCLUDE'd in /etc/system), b) Booting /etc/system from firmware, or c) Somehow causing /unix to not exist or to be older than /etc/system. (I don't think I've forgotten any other options). The most likely cause of your problem is that you're actually still running the old /unix. Another cause might be that something in /etc/profile is setting your ulimit before you get to a shell to type "ulimit". Remember, anyone can LOWER their ulimit, but only root can raise its. Anyhow, assuming the self-config reboot has been done, and your system has generated a new /unix, etc., I don't know of any quick and easy way of verifying that your new ulimit has "taken" (does anybody?). The ugly and disgusting way is to use /etc/master.d/kernel to calculate the correct offset into the correct structure in the kernel, and look at that value with crash's "od" command. Send me email if you want to do this. (An afterthought: when you said "I changed ULIMIT=..." you meant "changed" rather than "added", right? If I'm not mistaken, there is already a ULIMIT definition in the out-of-the-box /etc/master.d/kernel file, and if you added another one -above- that one, it probably wouldn't have any useful effect). ------------------------------------------------------------------------------ kevin@cfctech.cfc.com | Kevin Darcy, Unix Systems Administrator ...{sharkey,rphroy}!cfctech!kevin | Technical Services (CFC) Voice: (313) 948-4863 | Chrysler Corporation Fax: (313) 948-4975 | 27777 Franklin, Southfield, MI 48034 ------------------------------------------------------------------------------
Sm@cerberus.bhpese.oz.au (Scott Merrilees) (12/10/90)
kevin@cfctech.cfc.com (Kevin Darcy) writes: >Anyhow, assuming the self-config reboot has been done, and your system has >generated a new /unix, etc., I don't know of any quick and easy way of >verifying that your new ulimit has "taken" (does anybody?). I use crash(1m), and examine the u structure of a process. The ulimit is displayed in the file i/o section. This is on a 3b2/600 under V.3.1.1. Unfortunately, I also have V.2.x.x running on some machines, and for consistancy I change to default ulimit on all machines by having a front end program to init, which sets an appropriate ulimit, then exec's the real init. The only problem with this is that cron seems to set the ulimit back down, which is irritating, but solvable using a setuid root program that sets the specified ulimit, then exec's the specified command. Sm -- Scott Merrilees, BHP Information Technology, Newcastle, Australia Internet: Sm@bhpese.oz.au Phone: +61 49 402132
rad@genco.bungi.com (Bob Daniel) (12/12/90)
In article <1990Dec8.010027.23461@cfctech.cfc.com> kevin@cfctech.cfc.com (Kevin Darcy) writes: > >(An afterthought: when you said "I changed ULIMIT=..." you meant "changed" >rather than "added", right? If I'm not mistaken, there is already a ULIMIT >definition in the out-of-the-box /etc/master.d/kernel file, and if you added >another one -above- that one, it probably wouldn't have any useful effect). That is correct, there is already a ULIMIT entry and you want to CHANGE it rather than ADD it. If you add it below the original entry, my guess is that it would use the original entry (ie. 'grep' would grab the upper first).