Date: Mon, 24 Nov 1997 09:02:01 +1030 From: Greg Lehey <grog@lemis.com> To: Kender <kender@backpacker.laroche.edu> Cc: questions@FreeBSD.ORG Subject: Re: memory allocation question Message-ID: <19971124090201.53209@lemis.com> In-Reply-To: <Pine.BSF.3.96.971123142034.1299A-100000@backpacker.laroche.edu>; from Kender on Sun, Nov 23, 1997 at 02:34:58PM -0500 References: <Pine.BSF.3.96.971123142034.1299A-100000@backpacker.laroche.edu>
index | next in thread | previous in thread | raw e-mail
On Sun, Nov 23, 1997 at 02:34:58PM -0500, Kender wrote:
> Hi,
>
> I have a pentium 166, 4 GIG hd, 96megs of RAM, running FreeBSD 2.2.5,
> recently upgraded.
>
> I have two MOOs running on the system, which is almost exclusively devoted
> to them. When I start up the smaller (about 4 megs) of the two MOOs under
> my account,
> called kender, all is fine. The other MOO is larger (around 8megs
> database), but when I try starting it up with the other running, I get a
> panic of the moo's server from memory allocation. If I start it up under
> root's perms, all is
> fine. This has also happened on a box that is similar, after the
> login.conf was installed..
>
> We have determined that the problem may be with the new login.conf.
> My 'kender' account may be running out of allocated memory. One of
> my assistants tried adding a portion to the login.conf file named
> kender, but it didn't seem to help. We would like to give kender
> infinite memory. Could you help me with how we would go about
> setting that up? I wonder if we just didn't miss a step/setting.
Try this (from the upcoming second edition of "The Complete
FreeBSD"). If you have problems, please let me know--this is going to
press any day now.
Greg
Login classes
In UNIX tradition, root has been the owner of the universe. In a large
installation, this is rather primitive, and the 4.3BSD Net/2 relase introduced
a new concept, login classes, which determine session accounting, resource
limits and user environment settings. Various programs in the system use the
database described in /etc/login.conf to set up a user's login environment and
to enforce policy, accounting and administrative restrictions. The login class
database also provides the means by which users are able to be authenticated to
the system and the types of authentication available.
When creating a user, you may optionally enter a class name, which should match
an entry in/etc/login.conf--see page 135 for more details. If you don't, the
system will use the entry default for a non-root user. For the root user, the
system will use the entry root if it is present, and default otherwise.
The structure of the login configuration database is relatively extensive. It
describes a number of parameters, many of which can have two values: a current
value and a maximum value. On login, the system sets the values to the -cur
(current) value, but the user may, at his option, increase the value to the
-max (maximum) value. We'll look at the default entry for an example.
# Example defaults
# These settings are used by login(1) by default for classless users
# Note that entries like "cputime" set both "cputime-cur" and "cputime-max"
default:\
:cputime=infinity:\
:datasize-cur=64M:\
:stacksize-cur=64M:\
:memorylocked-cur=10M:\
:memoryuse-cur=100M:\
:filesize=infinity:\
:coredumpsize=infinity:\
:maxproc-cur=64:\
:openfiles-cur=64:\
:priority=0:\
:requirehome@:\
:umask=022:\
:tc=auth-defaults:
This entry defines the following parameters:
o Processes may use as much CPU time as they want. If you change this, you can
stop processes which use more than a specific amount of CPU time.
o The current maximum sizes of the user data segment and the stack are set to
64 MB. The entry doesn't define maximum values for these parameters.
o The user may lock a maximum of 10 MB of memory per process.
o The total memory use per process may not exceed 100 MB.
o There is no limit on the size of data files or core dump files that the user
may create.
o The user may have up to 64 processes.
o Each process may have up to 64 open files. For some programs, this could be
a limitation.
o The user need not have a home directory in order to log in. The @ symbol
specifies that the preceding symbol (requirehome) should be undefined. As a
result, the system does not require the home directory.
o By default, the umask is set to 022. See page 162 for more details of umask.
o The system uses the default authentication scheme for this user.
See the man page on page 879 for further details.
Referring to other classes
If you want to create a new class, you don't have to start from scratch. You
can derive the defaults from a different class. For example, if you have one
user on the system who uses a lot of memory, you might create a class like
this:
glutton:\
:tc=default:\
:memoryuse-cur=infinity:
The property tc refers to the default class. A good example of this is the
xuser class, designed for the needs of X11 users:
xuser:\
:manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\
:cputime=4h:\
:datasize=12M:\
:stacksize=4M:\
:filesize=8M:\
:memoryuse=16M:\
:openfiles=32:\
:maxproc=48:\
:tc=standard:
In this example, you'll notice also that the class definition defines a default
for the environment variable MANPATH.
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971124090201.53209>