Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!umich!sharkey!cfctech!kevin
From: kevin@cfctech.cfc.com (Kevin Darcy)
Newsgroups: comp.sys.att
Subject: Re: ULIMIT
Message-ID: <1990Dec8.010027.23461@cfctech.cfc.com>
Date: 8 Dec 90 01:00:27 GMT
References: <1454@msa3b.UUCP> <140@genco.bungi.com>
Reply-To: kevin@cfctech.cfc.com (Kevin Darcy)
Organization: Chrysler Financial Corporation, Southfield, MI.
Lines: 54

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
------------------------------------------------------------------------------