INIT.D(5) File Formats and Configurations INIT.D(5)

NAME

init.d - initialization and termination scripts for changing init
states

SYNOPSIS

/etc/init.d

DESCRIPTION

/etc/init.d is a directory containing initialization and termination
scripts for changing init states. These scripts are linked when
appropriate to files in the rc?.d directories, where `?' is a single
character corresponding to the init state. See init(8) for
definitions of the states.


The service management facility (see smf(7)) is the preferred
mechanism for service initiation and termination. The init.d and
rc?.d directories are obsolete, and are provided for compatibility
purposes only. Applications launched from these directories by
svc.startd(8) 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.

EXAMPLES

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(8) 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.

SEE ALSO

svcs(1), smf(7), init(8), svc.startd(8), svccfg(8)

NOTES

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(7)) is
the preferred delivery mechanism for persistently running
applications. 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(8).


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
subcommand in svccfg(8).

May 13, 2017 INIT.D(5)