rc2(8) System Manager's Manual rc2(8)NAME
rc2 - Run command script executed when entering a multiuser run level
The rc2 script contains run commands that enable initialization of the system to a multiuser state; run level 2. In addition to commands
listed within the script itself, rc2 contains instructions to run certain commands found in the /sbin/rc2.d directory. The script defines
the conditions under which the commands execute; some commands run if the system is booting, other commands execute if the system is chang-
ing run levels.
By convention, files in the /sbin/rc2.d directory begin with either the letter "K" or the letter "S" and are followed by a two-digit number
and a filename; for example: K00lpd S00savecore S25uucp
In general, the system starts commands that begin with the letter "S" and stops commands that begin with the letter "K." Commands that
begin with the letter "K" run only when the system is changing run levels from a higher to a lower level. Commands that begin with the
letter "S" run in all cases. The numbering of commands in the /sbin/rc2.d directory is important since the numbers are sorted and the com-
mands are run in ascending order. Files in the /sbin/rc2.d directory are normally links to files in the /etc/init.d directory.
An entry in the inittab file causes the system to execute the rc2 run commands, for example: s2:23:wait:/sbin/rc2 < /dev/console >
The following operations are typical of those that result from executing the rc2 script and the commands located in the /sbin/rc2.d direc-
tory. The operation depends on which state the system is entering or exiting. Setting the time zone Checking the current run level Stop-
ping network services and daemons Starting (or stopping) system services and daemons Starting the cron daemon Setting up paging and dump
facilities Setting up uucp files
Setting the TIMEZONE variable is one of the first operations completed by the rc2 script. This action provides the default time zone for
Specifies the command path Specifies the directory of commands that correspond to the run level
Commands: init(8), rc0(8), rc3(8) delim off
Check Out this Related Man Page
init.d - initialization and termination scripts for changing init states
/etc/init.d is a directory containing initialization and termination scripts for changing init states. These scripts are linked when appro-
priate to files in the rc?.d directories, where `?' is a single character corresponding to the init state. See init(1M) for definitions of
The service management facility (see smf(5)) is the preferred mechanism for service initiation and termination. The init.d and rc?.d direc-
tories are obsolete, and are provided for compatibility purposes only. Applications launched from these directories by svc.startd(1M) are
incomplete services, and will not be restarted on failure.
File names in rc?.d directories are of the form [SK]nn<init.d filename>, where S means start this job, K means kill this job, and nn is the
relative sequence number for killing or starting the job.
When entering a state (init S,0,2,3,etc.) the rc[S0-6] script executes those scripts in /etc/rc[S0-6].d that are prefixed with K followed
by those scripts prefixed with S. When executing each script in one of the /etc/rc[S0-6] directories, the /sbin/rc[S0-6] script passes a
single argument. It passes the argument 'stop' for scripts prefixed with K and the argument 'start' for scripts prefixed with S. There is
no harm in applying the same sequence number to multiple scripts. In this case the order of execution is deterministic but unspecified.
Guidelines for selecting sequence numbers are provided in README files located in the directory associated with that target state. For
example, /etc/rc[S0-6].d/README. Absence of a README file indicates that there are currently no established guidelines.
Do not put /etc/init.d in your $PATH. Having this directory in your $PATH can cause unexpected behavior. The programs in /etc/init.d are
associated with init state changes and, under normal circumstances, are not intended to be invoked from a command line.
Example 1: Example of /sbin/rc2.
When changing to init state 2 (multi-user mode, network resources not exported), /sbin/rc2 is initiated by the svc.startd(1M) process. The
following steps are performed by /sbin/rc2.
1. In the directory /etc/rc2.d are files used to stop processes that should not be running in state 2. The filenames are prefixed with K.
Each K file in the directory is executed (by /sbin/rc2) in alphanumeric order when the system enters init state 2. See example below.
2. Also in the rc2.d directory are files used to start processes that should be running in state 2. As in Step 1, each S file is executed.
Assume the file /etc/init.d/netdaemon is a script that will initiate networking daemons when given the argument 'start', and will terminate
the daemons if given the argument 'stop'. It is linked to /etc/rc2.d/S68netdaemon, and to /etc/rc0.d/K67netdaemon. The file is executed by
/etc/rc2.d/S68netdaemon start when init state 2 is entered and by /etc/rc0.d/K67netdaemon stop when shutting the system down.
svcs(1), init(1M), svc.startd(1M), svccfg(1M), smf(5)
Solaris now provides an expanded mechanism, which includes automated restart, for applications historically started via the init script
mechanism. The Service Management Facility (introduced in smf(5)) is the preferred delivery mechanism for persistently running applica-
tions. Existing init.d scripts will, however, continue to be executed according to the rules in this manual page. The details of execution
in relation to managed services are available in svc.startd(1M).
On earlier Solaris releases, a script named with a suffix of '.sh' would be sourced, allowing scripts to modify the environment of other
scripts executed later. This behavior is no longer supported; for altering the environment in which services are run, see the setenv sub-
command in svccfg(1M).
/sbin/rc2 has references to the obsolescent rc.d directory. These references are for compatibility with old INSTALL scripts. New INSTALL
scripts should use the init.d directory for related executables. The same is true for the shutdown.d directory.
17 Aug 2005 init.d(4)