Limits Database

The limits database is the database of user information that the Solaris Resource Manager software uses to perform all resource control. It contains one lnode per UID, which is accessed by using the UID as a direct index into the file. If there is an lnode for a numerically large UID, the limits database will appear to be quite large. However, where the UIDs of users in the system are not sequential, the limits database will have large gaps, or holes, and on a file system type that supports it, may be stored as a sparse file. This means that no disk blocks are actually allocated for storage of the "empty" sections of the file. ufs file systems support sparse files, but tmpfs file systems do not. See Saving and Restoring the Limits Database for the implications of sparse files on saving and restoring the limits database.

Whenever you create a new user, you must create a new lnode.

Creating the Limits Database

The Solaris Resource Manager startup file (/etc/init.d/init.srm) will create an initial limits database when invoked for the first time or at any boot if the file is missing.

The limits database typically resides in the /var/srm directory.

The limits database should be owned by root, group owned by root, and readable only by the owner. Write permission is not required since only kernel code with superuser credentials writes to the file.

If a user can write to the Solaris Resource Manager limits database, system security may be compromised.

Saving and Restoring the Limits Database

Because the limits database can be a sparse file, be careful when copying it. The file will most likely consume a lot of disk space if it is written by a utility that does not support sparse files, since the empty regions of the file will read as sequences of zeros and be written back out as real blocks instead of empty regions. This could happen if the file were being copied, backed up, or restored by a utility such as tar(1), cpio(1), or cp(1), although programs such as ufsdump(1M) and ufsrestore(1M) will preserve holes.

You can also back up and restore the limits database by using limreport to generate an ASCII version of the file and using limadm to re-create the original file from that saved ASCII version. For example, the command:

# limreport 'flag.real' - lname preserve > /var/tmp/savelnodes 

will create /var/tmp/savelnodes as an ASCII representation of the lnodes for each user in the password map. Note that this will not save lnodes for which there is no corresponding password map entry. At most, lnodes should exist for the set of all UIDs in the password map.

The command:

# limadm set -f - < /var/tmp/savelnodes

recreates the lnodes for which data was saved. This command will not delete lnodes that were not saved, so these techniques can also be used to save and restore selections of lnodes rather than the whole limits database.

The limreport and limadm Commands describes the use of the limreport and limadm commands in more detail. It is helpful for the administrator to be familiar with using these commands to save and restore lnodes, since it may be necessary to use them when a change to the interpretation of the lnode structure (as defined by the limits database) is made.

Because the contents of the limits database are changing regularly during normal system operation, perform backup operations while the system is quiescent, or in single-user mode. Similarly, restore an entire limits database only when the Solaris Resource Manager is not in use, such as when the system is in single-user mode.