Packaging/SysV Init Script

From openSUSE

Document SUSE_Package_Conventions/Init_Scripts should be merged into this one ...

openSUSE SysV Initscripts

This document describes the guidelines for SysV-style Initscripts, for use and inclusion in openSUSE packages.

They are LSB compilant, as explained at http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/sysinit.html

Name

The name of init scripts must be LSB compliant, so it must be listed at http://www.lanana.org/lsbreg/init/init.txt. A new name can be registered as described at http://www.lanana.org/lsbreg/instructions.html.

Initscripts on the filesystem

Packages with SysV-style initscripts must put any them into /etc/init.d. A rpm macro exists for this directory, %_initrddir.

Initscript packaging

Normally initscripts may not be marked as %config files.

Although init files live in /etc, they are scripts to be executed, not configured. Any configuration should be made available through /etc/sysconfig/<service> rather than in the init script itself. A valid exception to this rule would be existing packages where configuration is still done via the init file. In this case, the init file could be marked as %config following the rules from the Configuration files section to preserve a users configuration upon upgrade, hopefully so that the user can migrate said configuration to a new /etc/sysconfig/<service> config file.

Init scripts require to have 0755 or 0700 permissions.

Initscripts in spec file scriptlets

...

Requires(pre): %insserv_prereq %fillup_prereq

...

%install

...

install -D -m 755 service.init %{buildroot}%{_initddir}/service

...

mkdir -p %{buildroot}%{_sbindir}
ln -sf %{_initrddir}/service %{buildroot}%{_sbindir}/rcservice

...

%post
%fillup_and_insserv service
%restart_on_update service

%preun
%stop_on_removal service

%postun
%insserv_cleanup

...

%files
%defattr(-,root,root)
...
%{_initddir}/service
%{_sbindir}/rcservice

...

Initscript template

Below is the template for openSUSE SysV-style initscripts (also accessible from /etc/init.d/skeleton). The sections are explained in detail below.

#!/bin/sh
#
#     Template SUSE system startup script for example service/daemon FOO
#     Copyright (C) 1995--2005  Kurt Garloff, SUSE / Novell Inc.
#          
#     This library is free software; you can redistribute it and/or modify it
#     under the terms of the GNU Lesser General Public License as published by
#     the Free Software Foundation; either version 2.1 of the License, or (at
#     your option) any later version.
#			      
#     This library is distributed in the hope that it will be useful, but
#     WITHOUT ANY WARRANTY; without even the implied warranty of
#     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
#     Lesser General Public License for more details.
#      
#     You should have received a copy of the GNU Lesser General Public
#     License along with this library; if not, write to the Free Software
#     Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307,
#     USA.
#
# /etc/init.d/FOO
#   and its symbolic link
# /(usr/)sbin/rcFOO
#
# Template system startup script for some example service/daemon FOO
#
# LSB compatible service control script; see http://www.linuxbase.org/spec/
# 
# Note: This template uses functions rc_XXX defined in /etc/rc.status on
# UnitedLinux/SUSE/Novell based Linux distributions. If you want to base your
# script on this template and ensure that it works on non UL based LSB 
# compliant Linux distributions, you either have to provide the rc.status
# functions from UL or change the script to work without them.
# See skeleton.compat for a template that works with other distros as well.
#
### BEGIN INIT INFO
# Provides:          FOO
# Required-Start:    $syslog $remote_fs
# Should-Start:      $time ypbind smtp
# Required-Stop:     $syslog $remote_fs
# Should-Stop:       ypbind smtp
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: FOO XYZ daemon providing ZYX
# Description:       Start FOO to allow XY and provide YZ
#	continued on second line by '#<TAB>'
#	should contain enough info for the runlevel editor
#	to give admin some idea what this service does and
#	what it's needed for ...
#	(The Short-Description should already be a good hint.)
### END INIT INFO
# 
# Any extensions to the keywords given above should be preceeded by 
# X-VendorTag- (X-UnitedLinux- X-SuSE- for us) according to LSB.
# 
# Notes on Required-Start/Should-Start:
# * There are two different issues that are solved by Required-Start
#    and Should-Start
# (a) Hard dependencies: This is used by the runlevel editor to determine
#     which services absolutely need to be started to make the start of
#     this service make sense. Example: nfsserver should have
#     Required-Start: $portmap
#     Also, required services are started before the dependent ones.
#     The runlevel editor will warn about such missing hard dependencies
#     and suggest enabling. During system startup, you may expect an error,
#     if the dependency is not fulfilled.
# (b) Specifying the init script ordering, not real (hard) dependencies.
#     This is needed by insserv to determine which service should be
#     started first (and at a later stage what services can be started
#     in parallel). The tag Should-Start: is used for this.
#     It tells, that if a service is available, it should be started
#     before. If not, never mind.
# * When specifying hard dependencies or ordering requirements, you can 
#   use names of services (contents of their Provides: section)
#   or pseudo names starting with a $. The following ones are available
#   according to LSB (1.1):
#	$local_fs		all local file systems are mounted
#				(most services should need this!)
#	$remote_fs		all remote file systems are mounted
#				(note that /usr may be remote, so
#				 many services should Require this!)
#	$syslog			system logging facility up
#	$network		low level networking (eth card, ...)
#	$named			hostname resolution available
#	$netdaemons		all network daemons are running
#   The $netdaemons pseudo service has been removed in LSB 1.2.
#   For now, we still offer it for backward compatibility.
#   These are new (LSB 1.2):
#	$time			the system time has been set correctly	
#	$portmap		SunRPC portmapping service available
#   UnitedLinux extensions:
#	$ALL			indicates that a script should be inserted
#				at the end
# * The services specified in the stop tags 
#   (Required-Stop/Should-Stop)
#   specify which services need to be still running when this service
#   is shut down. Often the entries there are just copies or a subset 
#   from the respective start tag.
# * Should-Start/Stop are now part of LSB as of 2.0,
#   formerly SUSE/Unitedlinux used X-UnitedLinux-Should-Start/-Stop.
#   insserv does support both variants.
# * X-UnitedLinux-Default-Enabled: yes/no is used at installation time
#   (%fillup_and_insserv macro in %post of many RPMs) to specify whether
#   a startup script should default to be enabled after installation.
#   It's not used by insserv.
#
# Note on runlevels:
# 0 - halt/poweroff 			6 - reboot
# 1 - single user			2 - multiuser without network exported
# 3 - multiuser w/ network (text mode)  5 - multiuser w/ network and X11 (xdm)
# 
# Note on script names:
# http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/scrptnames.html
# A registry has been set up to manage the init script namespace.
# http://www.lanana.org/
# Please use the names already registered or register one or use a
# vendor prefix.


# Check for missing binaries (stale symlinks should not happen)
# Note: Special treatment of stop for LSB conformance
FOO_BIN=/usr/sbin/FOO
test -x $FOO_BIN || { echo "$FOO_BIN not installed"; 
	if [ "$1" = "stop" ]; then exit 0;
	else exit 5; fi; }

# Check for existence of needed config file and read it
FOO_CONFIG=/etc/sysconfig/FOO
test -r $FOO_CONFIG || { echo "$FOO_CONFIG not existing";
	if [ "$1" = "stop" ]; then exit 0;
	else exit 6; fi; }

# Read config	
. $FOO_CONFIG

# Source LSB init functions
# providing start_daemon, killproc, pidofproc, 
# log_success_msg, log_failure_msg and log_warning_msg.
# This is currently not used by UnitedLinux based distributions and
# not needed for init scripts for UnitedLinux only. If it is used,
# the functions from rc.status should not be sourced or used.
#. /lib/lsb/init-functions

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     be verbose in local rc status and clear it afterwards
#      rc_status -v -r  ditto and clear both the local and overall rc status
#      rc_status -s     display "skipped" and exit with status 3
#      rc_status -u     display "unused" and exit with status 3
#      rc_failed        set local and overall rc status to failed
#      rc_failed <num>  set local and overall rc status to <num>
#      rc_reset         clear both the local and overall rc status
#      rc_exit          exit appropriate to overall rc status
#      rc_active        checks whether a service is activated by symlinks
. /etc/rc.status

# Reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0	  - success
# 1       - generic or unspecified error
# 2       - invalid or excess argument(s)
# 3       - unimplemented feature (e.g. "reload")
# 4       - user had insufficient privileges
# 5       - program is not installed
# 6       - program is not configured
# 7       - program is not running
# 8--199  - reserved (8--99 LSB, 100--149 distrib, 150--199 appl)
# 
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signaling is not supported) are
# considered a success.

case "$1" in
    start)
	echo -n "Starting FOO "
	## Start daemon with startproc(8). If this fails
	## the return value is set appropriately by startproc.
	/sbin/startproc $FOO_BIN

	# Remember status and be verbose
	rc_status -v
	;;
    stop)
	echo -n "Shutting down FOO "
	## Stop daemon with killproc(8) and if this fails
	## killproc sets the return value according to LSB.

	/sbin/killproc -TERM $FOO_BIN

	# Remember status and be verbose
	rc_status -v
	;;
    try-restart|condrestart)
	## Do a restart only if the service was active before.
	## Note: try-restart is now part of LSB (as of 1.9).
	## RH has a similar command named condrestart.
	if test "$1" = "condrestart"; then
		echo "${attn} Use try-restart ${done}(LSB)${attn} rather than condrestart ${warn}(RH)${norm}"
	fi
	$0 status
	if test $? = 0; then
		$0 restart
	else
		rc_reset	# Not running is not a failure.
	fi
	# Remember status and be quiet
	rc_status
	;;
    restart)
	## Stop the service and regardless of whether it was
	## running or not, start it again.
	$0 stop
	$0 start

	# Remember status and be quiet
	rc_status
	;;
    force-reload)
	## Signal the daemon to reload its config. Most daemons
	## do this on signal 1 (SIGHUP).
	## If it does not support it, restart the service if it
	## is running.

	echo -n "Reload service FOO "
	## if it supports it:
	/sbin/killproc -HUP $FOO_BIN
	#touch /var/run/FOO.pid
	rc_status -v

	## Otherwise:
	#$0 try-restart
	#rc_status
	;;
    reload)
	## Like force-reload, but if daemon does not support
	## signaling, do nothing (!)

	# If it supports signaling:
	echo -n "Reload service FOO "
	/sbin/killproc -HUP $FOO_BIN
	#touch /var/run/FOO.pid
	rc_status -v
	
	## Otherwise if it does not support reload:
	#rc_failed 3
	#rc_status -v
	;;
    status)
	echo -n "Checking for service FOO "
	## Check status with checkproc(8), if process is running
	## checkproc will return with exit status 0.

	# Return value is slightly different for the status command:
	# 0 - service up and running
	# 1 - service dead, but /var/run/  pid  file exists
	# 2 - service dead, but /var/lock/ lock file exists
	# 3 - service not running (unused)
	# 4 - service status unknown :-(
	# 5--199 reserved (5--99 LSB, 100--149 distro, 150--199 appl.)
	
	# NOTE: checkproc returns LSB compliant status values.
	/sbin/checkproc $FOO_BIN
	# NOTE: rc_status knows that we called this init script with
	# "status" option and adapts its messages accordingly.
	rc_status -v
	;;
    probe)
	## Optional: Probe for the necessity of a reload, print out the
	## argument to this init script which is required for a reload.
	## Note: probe is not (yet) part of LSB (as of 1.9)

	test /etc/FOO/FOO.conf -nt /var/run/FOO.pid && echo reload
	;;
    *)
	echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload|probe}"
	exit 1
	;;
esac
rc_exit

LSB Header

LSB Headers are required for SysV-style initscripts and they must follow these guidelines.

The LSB Header is composed of the following sections:

• # Provides:
• # Required-Start:
• # Required-Stop:
• # Should-Start:
• # Should-Stop:
• # Default-Start:
• # Default-Stop:
• # Short-Description:
• # Description:

and the optional openSUSE specifc sections:

• # X-Start-Before:
• # X-Stop-After:

Boundary Comments

The LSB Header is bounded by comments, specifically, the beginning of the header is marked with:

### BEGIN INIT INFO

The end of the LSB Header is marked with:

### END INIT INFO

All LSB Header entries must have these boundary comments.

Facility Names

Boot facilities are used to indicate dependencies in initialization scripts. Facility names are assigned to scripts by the Provides: keyword. Facility names that begin with a dollar sign ('$') are reserved system facility names. Facility names are only recognized in the context of the initscript comment block (LSB Header) and are not available in the body of the init script. In particular, the use of the leading '$' character does not imply system facility names are subject to shell variable expansion, since they appear inside comments.

LSB compliant init implementations are supposed to provide the following System Facility names:

$local_fs</dt>

all local file systems are mounted</dd>

$network</dt>

basic networking support is available. Example: a server program could listen on a socket.</dd>

$named</dt>

IP name-to-address translation, using the interfaces described in this specification, are available to the level the system normally provides them. Example: if a DNS query daemon normally provides this facility, then that daemon has been started.</dd>

$portmap</dt>

daemons providing SunRPC/ONCRPC portmapping service as defined in RFC 1833: Binding Protocols for ONC RPC Version 2 (if present) are running.</dd>

$remote_fs</dt>

all remote file systems are available. In some configurations, file systems such as /usr may be remote. Many applications that require $local_fs will probably also require $remote_fs.</dd>

$syslog</dt>

system logger is operational.</dd>

$time</dt>

the system time has been set, for example by using a network-based time program such as ntp or rdate, or via the hardware Real Time Clock.</dd>

Beside the LSB compliant System Facilities as defined in /etc/insserv.conf on openSUSE the following System Facilities are known:

$all</dt>

This facility indicates that a service should be inserted at the end of all services. Clearly all services using this facility will be grouped into one starting order.</dd>

$null</dt>

Used to enforce an empty dependency in case of # Should-Stop: and # Required-Stop: otherwise insserv(8) assumes the same dependencies as specified at # Should-Start: respectivly at # Required-Start:.</dd>

Other (non-system) facilities may be defined in the # Provides: line in the LSB Header.

# Provides: line

The # Provides: line in the LSB Header lists any boot facilities that this service provides. Other services can reference these boot facilities in their # Required-Start: and # Required-Stop: lines.

# Provides: boot_facility_1 [boot_facility_2...]

When an initscript is run with a start argument, the boot facility or facilities specified by the Provides keyword shall be deemed present and hence init scripts which require those boot facilities should be started later. When an initscript is run with a stop argument, the boot facilities specified by the Provides keyword are deemed no longer present.

Example:

# Provides: sendmail

# Required-Start: line

The # Required-Start: line in the LSB Header lists any boot facilities which must be available during startup of this service.

# Required-Start: boot_facility_1 [boot_facility_2...]

This line is mandatory, if an initscript has no need for requiring other boot facilities before starting, you must use Required-Start, even if empty !

# Required-Stop: line

The # Required-Stop: line in the LSB Header lists any boot facilities which should NOT be stopped before shutting down this service.

# Required-Stop: boot_facility_1 [boot_facility_2...]

This line is optional, if an initscript has no need for requiring that other boot facilities must be stopped only after it has shutdown, then the line should be omitted.

# Should-Start: line

The # Should-Start: line in the LSB Header lists any facilities, which, if present, should be available during startup of this service. The intent is to allow for "optional" dependencies which do not cause the service to fail if a facility is not available.

# Should-Start: boot_facility_1 [boot_facility_2...]

This line is optional, if an initscript has no use for starting other optional dependencies before hand, it should be omitted.

# Should-Stop: line

The # Should-Stop: line in the LSB Header lists any facilities, which, if present, should only be stopped after shutting down this service. The intent is to allow for "optional" dependencies which do not cause the service to fail if a facility is not available.

# Should-Stop: boot_facility_1 [boot_facility_2...]

This line is optional, if an initscript has no use for preventing other optional dependencies from stopping until after it has shutdown, the line should be omitted.

# X-Start-Before: line

The # X-Start-Before: line in the LSB Header implies that the script using this keyword should be started before the specified facilities.

# X-Start-Before: boot_facility_1 [boot_facility_2...]

This line is optional and currently vendor specific (openSUSE).

# X-Stop-After: line

The # X-Stop-After: line in the LSB Header implies that the script using this keyword should be stopped after the specified facilities.

# X-Stop-After: boot_facility_1 [boot_facility_2...]

This line is optional and currently vendor specific (openSUSE).

Both # X-Start-Before: and # X-Stop-After: allows script writers to use dependencies in the new script without modifying other e.g. system init scripts.

How LSB Provides actually work on openSUSE

LSB based system uses /usr/lib/lsb/install_initd for script activation and /usr/lib/lsb/remove_initd for deactivation. When these tasks occur, the LSB dependencies are read, and the start and stop priorities of the scripts are then adjusted to satisfy those dependencies.

What this means that the LSB header dependencies are honored (albeit in a static mechanism). For override dependencies found in the LSB header the system tool insserv(8) can be used, for an further explanation how to do this the manual page insserv(8) should be read.

# Default-Start: line

The # Default-Start: line in the LSB Header lists the runlevels for which the service will be enabled by default. These runlevels are space-separated.

# Default-Start: run_level_1 [run_level_2...]

Each SystemV-style initscript which needs to start by default in any runlevel must include this line in the LSB Header. Only services which are really required for a vital system should define runlevels here. If the service does not start by default in any runlevel, this line should be omitted. For example, if a service starts by default in runlevels 3, 4, and 5 only, the LSB Header in the initscript would specify:

# Default-Start: 3 4 5

# Default-Stop: line

The # Default-Stop: line in the LSB Header lists the runlevels for which the service will not be started by default. These runlevels are space-separated, and must contain all of the numeric runlevels not used in the # Default-Start: line.

# Default-Stop: run_level_1 [run_level_2...]

Each SystemV-style initscript which needs to start by default in any runlevel must include this line in the LSB Header (if the # Default-Start: line is present, then there should also be a # Default-Stop: line.)

For example, if a service starts by default in runlevels 3, 4, and 5 only, then the # Default-Stop: line in the LSB Header has to specify runlevels 0, 1, 2, and 6:

# Default-Stop: 0 1 2 6

Please note, hat the # Default-Stop: are ignored in openSUSE, because the boot script concept uses a differential link scheme as described in the manual page init.d(7).

# Short-Description: line

The # Short-Description: line in the LSB Header provides a brief summary of the actions of the init script. This must be no longer than a single, 80 character line of text.

# Short-Description: This service is a mail server.

All openSUSE SysV-style initscripts must contain the # Short-Description: line in the LSB Header. It can be considered roughly equivalent to the Summary: field in an RPM spec file.

# Description: line

The # Description: line in the LSB Header provides a more complete description of the actions of the initscript. It may span mulitple lines, where each continuation line must begin with a '#' followed by tab character or a '#' followed by at least two space characters. The multiline description is terminated by the first line that does not match this criteria.

Example:

# Description: Bluetooth services for service discovery, authentication,
#              Human Interface Devices, etc.

All openSUSE SysV-style initscripts must contain the # Description: line in the LSB Header. It can be considered roughly equivalent to the %description section in an RPM spec file.

LSB Header Example

Here is a complete LSB Header to illustrate the correct use of the LSB Headers:

### BEGIN INIT INFO
# Provides:       OurDB
# Required-Start: $local_fs $network $remote_fs
# Required-Stop:  $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
#              engine used for illustrating init scripts
### END INIT INFO

Initialization of Environment Variables

Since initscripts may be run manually by a system administrator with non-standard environment variable values for PATH, USER, LOGNAME, etc., init scripts should not depend on the values of these environment variables. They should be set to known/default values if they are needed.

Required Actions

All SystemV-style initscripts on openSUSE must have implementations of the following actions:

start</dt>

starts the service</dd>

stop</dt>

stops the service</dd>

restart</dt>

stop and restart the service if the service is already running, otherwise just start the service</dd>

condrestart (and try-restart)</dt>

restart the service if the service is already running, if not, do nothing

reload</dt>

reload the configuration of the service without actually stopping and restarting the service (if the service does not support this, do nothing)</dd>

force-reload</dt>

reload the configuration of the service and restart it so that it takes effect</dd>

status</dt>

print the current status of the service</dd>

usage</dt>

by default, if the initscript is run without any action, it should list a "usage message" that has all actions (intended for use)</dd>

condrestart and try-restart

SystemV-style initscripts should support both the try-restart and condrestart action. These two actions are intended to serve an identical purpose, and must not differ in behavior. In fact, it is highly recommended that packagers implement try-restart and condrestart and as equivalent options in the case statement:

try-restart|condrestart)
    $0 status
    if test $? = 0; then
        $0 restart
    else
        rc_reset
    fi
    rc_status
    ;;

Initscripts must be on their best behavior

SystemV-style initscripts must behave sensibly if they are started when the service is already running, or stopped when the service is not running. They must not kill unrelated (but perhaps, similarly-named) user processes as a result of their normal actions. The best way to achieve this is to use the init-script functions provided by /etc/rc.status:

# Source function library.
. /etc/rc.status
rc_reset

and the systems tools /sbin/start_daemon or /sbin/startproc for start a process, /sbin/killproc to stop a process, and /sbin/checkproc to check for a running process. For an furhter explanation the manual pages of start_daemon(8) or startproc(8), killproc(8), and checkproc(8) should be consulted.

If a service reloads its configuration automatically (as in the case of cron, for example), the reload action of the initscript must behave as if the configuration was reloaded successfully. The restart, condrestart, try-restart, reload and force-reload actions may be atomic; that is if a service is known not to be operational after a restart or reload, the script may return an error without any further action.

Exit Codes for the Status Action

If the status action is requested, the initscript must return the correct exit status code, from this list:

0:	program is running or service is OK
1:	program is dead and /var/run pid file exists
2:	program is dead and /var/lock lock file exists
3:	program is not running
4:	program or service status is unknown
5-99:	reserved for future LSB use
100-149:	reserved for distribution use
150-199:	reserved for application use
200-254:	reserved

Fedora does not currently define any distribution specific status codes.

Exit Codes for non-Status Actions

For all other initscript actions, the init script must return an exit status of zero if the action was successful. In addition to straightforward success, the following situations are also to be considered successful:

• restarting a service (instead of reloading it) with the force-reload argument
• running start on a service already running
• running stop on a service already stopped or not running
• running restart on a service already stopped or not running
• running condrestart or try-restart on a service already stopped or not running

In case of an error while processing any non-Status initscript action, the initscript must print an error message and exit with the appropriate non-zero status code:

1:	generic or unspecified error (current practice)
2:	invalid or excess argument(s)
3:	unimplemented feature (for example, "reload")
4:	user had insufficient privilege
5:	program is not installed
6:	program is not configured
7:	program is not running
8-99:	reserved for future LSB use
100-149:	reserved for distribution use
150-199:	reserved for application use
200-254:	reserved

Fedora does not currently define any distribution specific status codes.

Other Actions

You are not prohibited from adding other commands, but you should list all commands which you intend to be used interactively to the usage message.

Functions in /etc/rc.status

Here are some commonly used functions provided by /etc/rc.satus:

• rc_check check and set local and overall rc status
• rc_status check and set local and overall rc status
• rc_status -v be verbose in local rc status and clear it afterwards
• rc_status -v -r ditto and clear both the local and overall rc status
• rc_status -s display "skipped" and exit with status 3
• rc_status -u display "unused" and exit with status 3
• rc_failed set local and overall rc status to failed
• rc_failed <num> set local and overall rc status to <num>
• rc_reset clear both the local and overall rc status
• rc_exit exit appropriate to overall rc status
• rc_active checks whether a service is activated by symlinks

System tools for SystemV initscripts

start_daemon(8) and startproc(8) tools

• start_daemon Starts a daemon, if it is not already running.
• startproc Starts a process as a daemon, if it is not already running.

start_daemon [-fLve] [-n +/-<prio>] [-u user] [-g group] [-l log_file|-q|-d] [-p pid_file]
          [-i ignore_file][-c root]/path/to/executable [arguments for executable]


startproc [-fLves] [[-n ]+/-<prio>] [-(t|T) <sec>] [-u user] [-g group] [-l log_file|-q|-d] [-p pid_file]
          [-i ignore_file] [-c root] /path/to/executable [arguments for executable]

killproc(8) tool

Sends a signal to the program; by default it sends a SIGTERM, and if the process doesn't die, it sends a SIGKILL a few seconds later. It also tries to remove the pidfile, if it finds one.

killproc [-vqLN] [-g|-G] [-p pid_file] [-i ingnore_file] [-c root] [-t <sec>] [-<SIG>] /full/path/to/executable

killproc -n [-vq] [-g|-G] [-t <sec>] [-<SIG>] name_of_kernel_thread

killproc    [-vq] [-g|-G] [-t <sec>] [-<SIG>] basename_of_executable

checkproc(8) and pidofproc(8) tool

Try to find the status and pid of a program; checking likely pid files. Mainly the pidofproc is the verbose version of checkproc.

checkproc [-vLkNz] [-p pid_file] [-i ingnore_file] [-c root] /full/path/to/executable

checkproc -n [-vk] name_of_kernel_thread

checkproc    [-vk] basename_of_executable

pidofproc [-LkNz] [-p pid_file] [-i ingnore_file] [-c root] /full/path/to/executable

pidofproc -n [-k] name_of_kernel_thread

pidofproc    [-k] basename_of_executable

LSB shell functions

the above systems tools will be alos provided by the shell functions found in /lib/lsb/init-functions:

# Load the LSB shell functions
. /lib/lsb/init-functions

together with the synopsis specified by the LSB 3.1 and higher:

start_daemon [-f] [-n +/-<prio>] /path/to/executable [arguments for executable]
killproc [-p pid_file] /full/path/to/executable [-<SIG>]
pidofproc [-p pid_file] /full/path/to/executable