The /Etc/system File When Solaris is first installed, the /etc/system file contains only comments, but it can be updated in various ways to configure the kernel at boot-time. Each comment section describes a certain type of modification that can be made, along with some examples. These include the following: Set the search path for kernel modules. Set a filesystem type for the root filesystem. Define kernel modules that should not be loaded. Define kernel modules that must be loaded at boot-time. Set kernel parameters.
Kernel Parameters A number of aspects that are controlled by the kernel can be changed by altering the values assigned to various kernel parameters. "Tuning the kernel" is often thought of as some arcane ritual similar to alchemy that can only be performed by seventh-level UNIX Wizards and above. In reality, it is a fairly straightforward task that is considered to be slightly mystical probably because it used to be much more complicated; also, it is a task that some system administrators will never actually have to do. Listing Kernel Parameters The names of the kernel parameters and their current values can be displayed using the sysdef command as follows: hydrogen# sysdef <lines removed for clarity> * * Tunable Parameters * 1970176 maximum memory allowed in buffer cache (bufhwm) 1514 maximum number of processes (v.v_proc) 99 maximum global priority in sys class (MAXCLSYSPRI) 1509 maximum processes per user id (v.v_maxup) 30 auto update time limit in seconds (NAUTOUP) 25 page stealing low water mark (GPGSLO) 5 fsflush run rate (FSFLUSHR) 25 minimum resident memory for avoiding deadlock (MINARMEM) 25 minimum swapable memory for avoiding deadlock (MINASMEM) * * Utsname Tunables * 5.7 release (REL) hydrogen node name (NODE) SunOS system name (SYS) Generic_106541-08 version (VER) * * Process Resource Limit Tunables (Current:Maximum) * 0xffffffff:0xfffffffd cpu time 0xffffffff:0xfffffffd file size 0xffffffff:0xfffffffd heap size 0xffffffff:0xfffffffd stack size 0xffffffff:0xfffffffd core file size 0xffffffff:0xfffffffd file descriptors 0x00000000:0x00800000 mapped memory * * Streams Tunables * 9 maximum number of pushes allowed (NSTRPUSH) 65536 maximum stream message size (STRMSGSZ) 1024 max size of ctl part of message (STRCTLSZ) * * IPC Messages * 0 entries in msg map (MSGMAP) 0 max message size (MSGMAX) 0 max bytes on queue (MSGMNB) 0 message queue identifiers (MSGMNI) 0 message segment size (MSGSSZ) 0 system message headers (MSGTQL) 0 message segments (MSGSEG) * * IPC Semaphores * 10 entries in semaphore map (SEMMAP) 10 semaphore identifiers (SEMMNI) 60 semaphores in system (SEMMNS) 30 undo structures in system (SEMMNU) 25 max semaphores per id (SEMMSL) 10 max operations per semop call (SEMOPM) 10 max undo entries per process (SEMUME) 32767 semaphore maximum value (SEMVMX) 16384 adjust on exit max value (SEMAEM) * * IPC Shared Memory * 1048576 max shared memory segment size (SHMMAX) 1 min shared memory segment size (SHMMIN) 100 shared memory identifiers (SHMMNI) 6 max attached shm segments per process (SHMSEG) * * Time Sharing Scheduler Tunables * 60 maximum time sharing user priority (TSMAXUPRI) SYS system class name (SYS_NAME) hydrogen# The sysdef command produces many pages of output, most of which have been removed from the above example to display only tuneable parameters. Viewed as a whole, the output would also list all hardware devices, pseudo devices, system devices, and loadable kernel modules. Modifying Kernel Parameters If you wish to change the current value of any kernel parameter, you need to add an entry to the /etc/systems file. When the kernel sets up all its parameters at boot-time, it will use the default value for each one unless it sees a set command for that parameter in the systems file. The parameter "max_nprocs" defines the maximum number of processes that can run on the system at any one time. In the above example, we can see that it is currently set to 1,514 (though unfortunately the output from sysdef doesn't tell us that "max_nprocs" is the name of the parameter). This controls the number of allowed processes by setting the size of the process table, as each process takes up one slot in the table. If we found that this was not enough for the needs of our system, we could add an entry to /etc/system to increase the value of "max_nprocs" and so increase the size of the process table. You can tell that your process table is full if you get messages such as "cannot fork" when trying to run commands. If you do get such messages, it does not necessarily mean that you should immediately increase the "max_nprocs" parameter; the process table could be full because an out-of-control process has filled it by continuously spawning subprocesses. At first thought, this might be a problem because if the process table is full, how can the system administrator kill the rogue process, as there is no room in the process table to run the kill command? Fortunately, this situation is prevented by the fact that the last slot in the process table may only be taken by a process run by the root user. Therefore, providing the rogue process is not running as root, the problem can be resolved without resorting to a reboot. Assuming that we are sure we do need to increase the size of the process table (and we have decided it should be set at 2,000), we would add the following entry to the /etc/system file: set max_nprocs = 2000 Once we have rebooted the system we can check that the new value has been assigned: hydrogen# sysdef | grep process 2000 maximum number of processes (v.v_proc) 1995 maximum processes per user id (v.v_maxup) 10 max undo entries per process (SEMUME) 6 max attached shm segments per process (SHMSEG) hydrogen# By far the most likely reason for needing to alter the values of system parameters is to meet the requirements of an application or database, in which case the installation guide will explain which parameters need altering and how you should calculate the values to set. The /etc/system file is very important as it can greatly affect the way the kernel is configured and setting something incorrectly could cause the system to become unusable. Therefore, it is important that we always make a backup copy before changing the file. That way, if the system fails to boot successfully, we can boot the system with boot -a, which will cause us to be prompted for the location of the system file. At that time, we can specify the backup copy, which we know works (see Chapter 2, "Booting and Halting the System"). If we don't have a backup copy, we could always specify the file /dev/null as the system file, which should act as an empty file and cause the system to set all kernel parameters to their default values. | 
