Solaris Run States

Solaris init states refer to the level of services provided by the system. The exact services and processes run at each init level are determined by the scripts in the /etc/rc#.d directories. The default service levels for each init state are listed below:

0: The system is at the PROM monitor (ok>) or security monitor (>) prompt. It is safe to shut down the system when it is at this init state.
1, s or S: This state is known as "single-user" or "system administrator" mode. Root is the only user on the system, and only basic kernel functions are enabled. A limited number of filesystems (usually only root and /usr) are mounted. This init state is often used for sensitive functions (such as kernel libc patches) or while troubleshooting a problem that is keeping the system from booting into multiuser mode.
2: Multiple users can log in. Most system services (except for NFS server and printer resource sharing) are enabled.
3: Normal operating state. NFS and printer sharing is enabled, where appropriate.
4: Usually undefined.
5: Associated with the boot -acommand. The system is taken to init 0 and an interactive boot is started.
6: Reboot. This state takes the system to init state 0 and then to the default init state (usually 3, but can be redefined in the /etc/inittab file).

The init states are defined in the /etc/inittab file, which usually points at the scripts in /sbin/rcrun-level. These scripts in turn examine the contents of the /etc/rcrun-level directories. The scripts in these directories whose names begin with the letter K are run in "stop" mode first in alphabetical order. Then the scripts whose names begin with the letter S are run in "start" mode in alphabetical order.

To get to a desired run level n, each of the rc (run control) scripts from 1 to n is run. To get to run level 0, the K scripts are run in each rc#.d directory between the current run level and 0 in reverse numerical order.

In the default configuration, the rc scripts accomplish the following tasks:

/sbin/rc0
- Stop system services/daemons.
- Terminate running processes.
- Unmount all file systems.
/sbin/rc1
- Stop system services/daemons.
- Terminate running processes.
- Unmount all file systems.
- Bring up the system in single-user mode.
/sbin/rc2
- Set the TIMEZONE variable.
- Stop the print and NFS services.
- Stop the vold daemon.
- Mount local filesystems, enable disk quotas (as appropriate).
- Remove temporary files.
- Create new device entries if this is the result of a boot -r.
- Save a core file if enabled.
- Configure system accounting, (as appropriate).
- Set the default router.
- Set the NIS domain.
- Set up the network interfaces appropriately.
- Start inetd.
- Start named, if appopriate.
- Start rpcbind.
- Start kerbd (the Kerberos client daemon) if appropriate.
- Start ypbind or rpc.nisd as appropriate.
- Start keyserv.
- Start statd and lockd.
- Mount NFS filesystems from /etc/vfstab.
- Start the automounter.
- Start cron.
- Start lp daemons, as appropriate.
- Start sendmail.
/sbin/rc3
- Clean up sharetab.
- Start nfsd and mountd.
- Start rarpd and rpc.bootparamd, as appropriate.
/sbin/rc4 is usually not defined. It can be used in a non-default configuration to achieve a tailored run level.
/sbin/rc5
- Kill print daemons.
- Unmount local file systems.
- Kill syslogd.
- Unmount NFS file systems.
- Stop NFS services.
- Stop NIS services.
- Stop RPC services.
- Stop cron services.
- Stop statd and lockd (NFS client services).
- Kill active processes.
- Initiate an interactive boot.
/sbin/rc6
- Stop system services/daemons.
- Terminate running processes.
- Unmount all file systems.
- Boots to the initdefault level from the /etc/inittab
/sbin/rcS: This run level differs from 1 in the following particulars:
- Minimal network is established.
- System name is set.
- root, /usr and /usr/kvm filesystems are checked and mounted (if necessary).
- Pseudo file systems proc and /dev/ are started.
- Rebuilds device entries (for reconfiguration reboots only).

Solaris Run level change

I need to find out runlevel related information, as you may need to change runlevel for following causes:

Halt/reboot system when shutdown command don’t work
Troubleshooting or repairing system

The first thing I noticed was /etc/inittab file is different from the Linux version. However, runlevel are quite identical

Default Solaris Run Level

S : Single user state (useful for recovery)
0 : Access Sun Firmware ( ok> prompt)
1 : System administrator mode
2 : Multi-user w/o NFS
3 : Multi-user with NFS
4 : Unused
5 : Completely shutdown the host (like performing a power-off @ OBP) [ thanks to Marco ]
6 : Reboot but depend upon initdefault entry in /etc/inittab

Solaris Find out runlevel
To find out current runlevel use who command:

$ who -r

Output:

  .       run-level 3  Mar  3 14:04     3      0  S

Solaris changing runlevels after bootup
You need to use init command, for example change runlevel to 2.

# /sbin/init 2

Solaris changing the default runlevel
An entry with initdefault (in /etc/inittab file) is scanned only when init is initially invoked. init uses this entry to determine which run level to enter initially.

Open /etc/inittab file:

# vi /etc/inittab

Find out this entry:

is:3:initdefault:

Change is:3 to number you want, don't use S, 0, 6 ;). Save file.

See also

Read man page of inittab and init for more information.
There is also a nice program called runlevel for Solaris.

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 28, 2008