cssd(1m) [sunos man page]
cssd(1M) System Administration Commands cssd(1M) NAME
cssd - daemon which invokes and watches the CSs SYNOPSIS
/usr/sbin/cssd [-f filename] AVAILABILITY
SUNWjfpu DESCRIPTION
cssd is the command which invokes and watches CS available in MLE (Multi Language Environment). After five seconds of the ending (includ- ing abnormal termination) of a CS, cssd re-invokes the CS. CS STARTING INFORMATION FILE In a CS starting information file, /etc/css.conf by default, some CS starting information directories are described. This file can be cus- tomized. cssd reads /etc/css.conf to get CS starting information directories, and then it invokes all executable files in the directories. Usually, each CS itself is not placed in the directories and is invoked indirectly from a script in one of the directories. CS STARTING SCRIPT A CS starting script is located in a CS starting information directory. cssd reads all CS starting information directories in the sequence specified in /etc/css.conf and finds to invoke all CS starting scripts. If two or more scripts which have the same filename are found, cssd invokes only the first one. UPDATING CS STARTING INFORMAION When cssd receives signal SIGHUP , it re-reads /etc/css.conf and re-finds all CS starting scripts, and then restarts, starts or terminates each script according to the following conditions. A script whose modified time is changed (is to be restarted) A script which is newly added (is to be started) A script which is deleted (is to be terminated) TO TERMINATE When cssd receives signal SIGTERM, it sends SIGTERM to each CS under the cssd's management and terminates itself (in general, each CS also terminates with the signal). ERROR INFORMATION As a facility of daemon, cssd sends error information at level `err' , and invoke/re-invoke information at level `notice' to syslogd(1M). OPTION
-f filenaSpecify a CS starting information file. Without this option, /etc/css.conf is used. FILE
/etc/css.conf file for the information of CSs by default SEE ALSO
css.conf(4), syslogd(1M) BUGS
If a CS starting script is programmed so that itself is exec-ed by a CS, cssd understands that the process of the CS starting script is terminated in spite of the CS's termination, and so puts syslog message out. SunOS 5.10 10 Jan 2003 cssd(1M)
Check Out this Related Man Page
init.d(4) init.d(4) NAME
init.d - initialization and termination scripts for changing init states SYNOPSIS
/etc/init.d /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 states. 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)