INIT.D(5) File Formats and Configurations INIT.D(5)
NAME
init.d - initialization and termination scripts for changing init states
SYNOPSIS
/etc/init.dDESCRIPTION
/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)