View source for Init systems and service management

{{#addbodyclass:tag_tech}}
{{ShellsAndAdmin}}

{{notes}}

==tl;dr, commands==
===SysV start/stop===
 # historically:
 /etc/init.d/apache2 start


The {{inlinecode|[[#One-time_start.2Fstop.2C_in_all_.28in_theory.29|service]]}} script, when present, likely wraps at least sysv, so these days you can often also do the following and it'll also work on systems with newer service managers:
 service apache2 start

===SysV enable/disable===
{{stub}}

Note: '''SysV and its various imitations may vary a little in the details.'''

SysV init basically runs entries in specific directories - which are typically symlinks.
* from directories under /etc/rc.d/ representing runlevels  
* to the scripts in a place like /etc/init.d
* with names start with S10service and K40service, where S and K means start and kill, and the number is the priority within this runlevel

As such, going to a specific runlevel runs a bunch of starts and stops.


As it's ''work'' to alter /etc/rc.d/ contents manually, so the contents of these directories are  
sometimes tweaked via convenience tools such as 
* <tt>update-rc.d</tt> (CLI)
* <tt>chkconfig</tt> (CLI)
* <tt>rcconf</tt> (CLI curses)
* <tt>sysv-rc-conf</tt> (CLI curses)
* <tt>bum</tt> (GUI)
* <tt>jobs-admin</tt> (GUI)

* sometimes computed from something else

===upstart start/stop===
initctl interacts with upstart's init daemon.

 initctl start apache2
 initctl stop apache2


There are specific helpers scripts for less typing:

'''One-time start/stop:'''
 start apache2
 stop apache2
 restart apache2
 status apache2


(The {{inlinecode|[[#One-time_start.2Fstop.2C_in_all_.28in_theory.29|service]]}} script, when present, likely wraps upstart)

===upstart enable/disable===

Via basic configuration:
* a service definition placed in {{inlinecode|/etc/init}} will be used
* its startup requirements can be be configured
: e.g. #commenting the <tt>start on</tt> line will effectively disable it.


{{comment|(It's arguably a little cleaner to disable existing services via overrides. That is, you can create a {{inlinecode|/etc/init/<service>.override}} and having it contain {{inlinecode|manual}}, because (man page:) "If an override file is present, the stanzas it contains take  precedence over those equivalently named stanzas in the corresponding configuration file [...]". This effectively allows local exceptions without touching the service definitions.)}}

===systemd start/stop===
systemctl talks to the systemd daemon. 

There are some scripts around it.

<syntaxhighlight lang="bash">
systemctl start apache2
systemctl status apache2.service
# .service is optional
</syntaxhighlight >


{{comment|The {{inlinecode|[[#One-time_start.2Fstop.2C_in_all_.28in_theory.29|service]]}} script, when present, likely wraps systemd, as does RHEL/Centos's {{inlinecode|chkconfig}} - see below)}}

===systemd enable/disable===
{{stub}}

If you have just edited it you need to do a
 systemctl daemon-reload
first, otherwise you can skip that.


Enabling services basically means "putting it in a target (unit)" (read up for details), so
<syntaxhighlight lang="bash">
systemctl enable apache2
systemctl disable apache2
</syntaxhighlight >
'''systemctl''' typically alters <tt>/etc/systemd/system/multi-user.target.wants/</tt>, which is similar to what historically was runlevel 3 [https://www.freedesktop.org/software/systemd/man/systemd.target.html].



Overview of all services:
 # active services
 systemctl list-units --type=service
 # _all_ services
 systemctl list-units --type=service --all

===Start/stop in all (in theory)===

The {{inlinecode|service}} command was initially meant to run sysv scripts in a predictable environment rather than your shell's {{verify}}.<!-- {{comment|(specifically, it removes most environment variables, and sets working directory to /. This is cleaner, though often makes little difference.)}}-->


Then people used it to wrap other things, also during transitions between systems,
so '''if present''' it's likely to control 
sysv, upstart (initctl commands), systemd (systemctl commands), and openrc, whichever are applicable.

While you can't count on it always being there, it's convenient when it is.
 service apache2 start
 service apache2 stop
 service apache2 restart
 service apache2 status


To enable/disable services you still need the system-specific commands.


<!--
===Other notes===

* jobs-admin
: sysv and apparently upstart
: https://wiki.ubuntu.com/DesktopTeam/Specs/Maverick/UpstartJobAdministration
-->


<!--
==Which does my system use?==

Upstart was good, but fired people up and ended up as transitional;
most distos that adopted it moved on to systemd.

Perhaps the easiest way to tell is to look for supporting :
 ps aux | grep -E '(upstart|systemd)'



[http://manpages.ubuntu.com/manpages/xenial/en/man3/sd_booted.3.html Systemd docs] mention that the existence of /run/systemd/system/ is a strong indicator for systemd.


Also there is:
 init --version
Upstart mentions upstart, systemd says invalid option,


-->


===Also, chkconfig===
RHEL/Centos also has '''chkconfig''', which seems to unify systemd (via systemctl), sysv, and xinetd.
It has historical origins, like {{inlinecode|service}}.
<syntaxhighlight lang="bash">
chkconfig --list             
 
# add to startup. This will also turn them on for, by default, runlevels 2 through 5
chkconfig --add iptables
# remove
chkconfig --del ip6tables
# turn on/off at said runlevels
chkconfig mariadb on
# turn on/off at a specific runlevel
chkconfig ip6tables --level 2 off
 
# check whether configured for startup: add only service name
chkconfig network && echo "Network service is configured for startup"
# check whether configured for startup in specific runlevel: name and --level
chkconfig network --level 2 && echo "Network service is configured for startup in level 2"
</syntaxhighlight >

<!--
https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units
-->

==init/service systems in more detail==
===SysV-style init===
{{stub}}

Runlevels and init scripts in imitation of how [https://en.wikipedia.org/wiki/UNIX_System_V SYSV] did it {{comment|(and of little else from SYSV)}}

* scripts in <tt>/etc/init.d/</tt> are from used to start and control services
: many controlling a single process.

* These scripts can be run directly (e.g. {{inlinecode|/etc/init.d/apache start}}).

* ...but usually the basic idea is that sysv starts a particular service in a [[runlevel]] (mostly made to deal with order of services at boot time)

<!--
Note that runlevels are not a kernel thing, they're purely part of this sort of init system.
-->

{{comment|Most of these scripts stay short by using {{search|man runscript|provisions from <tt>/sbin/runscript</tt>}} via a [[hashbang]], which handles most of the boilerplate and means you only need to flesh out out a few major functions.
It's also not unusual to see init scripts themselves use <tt>start-stop-daemon</tt> to start their target executable, e.g. for its [[#pidfiles|pidfile]]-handling convenience.}}

<!--
Runlevels are not used so much anymore

Exceptions to "in response to a runlevel change" includes things like shutdown.sh, reboot.sh, halt.sh, (may be called by init directly, e.g. shutdown.sh in response to Ctrl + Alt + Del) and supporting scripts like functions.sh, depscan.sh.
-->


From the perspective of some later, fancier alternatives, things that sysvinit lacks include:
: dependencies - e.g. starting networking before a networked daemon can only be handled through ranking services and starting them in series
: can't start things lazily (only when needed, also including dependencies)
: can't start unrelated things in parallel



====SysV init scripts====
{{stub}}

<!--
: '''On arguments'''

* start (technically the only one truly required one)

* stop (typically also useful)


* <tt>depend</tt> - list dependencies, order preferences. 
** depend: many things will say they depend on logging, network daemons will say they depend on networking, some may depend on a database to do their thing
** order: for example, my apache says it ought to be started after sshd
** use: 

* <tt>restart</tt> - stop (if running), then start
* <tt>reload</tt> (if sensible) - reload the configuration without restarting (to avoid service interruption)
* <tt>force-reload</tt>

* <tt>status</tt> - some (human-readable) status report. May be no more than a message stating that a service has been started or not.
* <tt>checkconfig</tt> - check whether the configuration file contains errors
** a reload and restart may be conditional on this succeeding

If you want to see how involved you can get, look at apache's init script.
-->

<!--
=====Example scripts and snippets=====

Various init scripts use <tt>runscript</tt> as the interpreter, to avoid having to write some boilerplate. You don't have to.

Various scripts use start-stop-daemon to handle some pidfile-related stuff. Again, you don't have to.


A fairly minimal example (that still uses a pidfile to potentially allow multiple instances):
<syntaxhighlight lang="bash">
#!/bin/sh
 
case "$1" in
start)  echo "Starting..."
        /sbin/start-stop-daemon --start --exec /usr/local/bin/me -m --pidfile /var/run/me.pid
 
        ;;
stop)   echo "Stopping..."
        /sbin/start-stop-daemon --stop --pidfile /var/run/me.pid
        ;;
*)      echo "Usage: /etc/init.d/me start|stop"
        exit 1
        ;;
esac
exit 0
</syntaxhighlight >


A more involved example:
<syntaxhighlight lang="bash">
#!/sbin/runscript
#
# NAMEEXEC can be handy to define once and reuse when you use it as a process spec.
#

PIDFILE="/var/run/NAME.pid"
NAMEEXEC="/usr/bin/NAME"

depend() {
    # lists things we need. For example, various services will have:
    need net
}

checkconfig() {
  # Some add basic config checking, so that we can avoid a restart being an effective stop,
  # and/or to give a decent suggestion about the problem.
  # In this case, $1 may mention "start" or "stop" (see calls below) which can be useful
  if [[ -z "${NAME_OPTS}" ]]; then
     eerror "You have not set any options"
     eerror "Edit /etc/conf.d/NAME before starting this service." 
            # ...or something. That's not actually loaded in this example.
     return 1
  fi
}

start() {
   # commands that start the service and may store some state necessary for stopping it
   checkconfig start || return 1
   ebegin "Starting NAME"
   start-stop-daemon --start --quiet \
               --exec ${NAMEEXEC} ${NAME_OPTS} --pidfile ${PIDFILE} \
               -- --pid-file ${NAME_PID}               
   eend $? "Failed to start NAME"
}

stop() {
   checkconfig stop || return 2
   ebegin "Stopping NAME"
   start-stop-daemon --stop --quiet --pidfile ${PIDFILE}
   eend $? "Failed to stop NAME"
}
</syntaxhighlight >
-->

<!--
=====start=====

The following two functions are functionally quite similar:

 start() {
        ebegin "Starting boogacron"
        start-stop-daemon --start --quiet --exec /usr/bin/booga
        eend $?
 }

 start() {
        ebegin "Starting boogacron"
        /usr/bin/booga ${BOOGACRON_OPTS} 2>&1
        eend $?
 }


=====stop=====
 stop() {
        ebegin "Stopping boogacron"
        start-stop-daemon --stop --quiet --exec /usr/bin/booga
        eend $?
 }

 stop() {
        ebegin "Stopping boogacron"
        start-stop-daemon --pidfile /var/run/booga.pid --stop
        eend $?
 }


 stop() {
        ebegin "Stopping boogacron"
        start-stop-daemon --stop --quiet --pidfile /var/run/boogacron.pid --exec /usr/sbin/booga
        local ret=$?
        rm -f /var/run/boogacron.pid
        eend ${ret}
 }


=====opts=====
opts="${opts} restartdelay"

 restartdelay() {
   stop
   sleep 3    # Wait 3 seconds before starting again
   start
 }
-->

<!--
====<tt>runscript</tt> provisions====
http://www.linuxhowtos.org/manpages/8/runscript.htm
=====reporting=====
<tt>ebegin<tt> and <tt>eend</tt> are used to print such athe user of attempts - they lead to .

<tt>eerror</tt> is used to signal errors (particularly those that can span lines)


=====<tt>depend</tt>=====
* 'provide' provides virtual services, so that you can use/need something like 'cron', which any specific cron package can supply
* 'need': start these services first. If they don't start, we refuse to start.
* 'use':  start these services first. If they don't start, we try to start.

* 'before' and 'after' are not dependencies, just specify that if some other service is to  be loaded, in what order to do the loading
 depend() {
        use net logger clock hostname
        need dbus
        before nfs
        after logger
        provide cron 
 }

-->

===upstart===

See [[Upstart notes]]

===systemd===

See [[Systemd notes]]

===OpenRC===
Like SysV, but cleaner and easier to handle. {{verify}}

https://wiki.gentoo.org/wiki/Project:OpenRC

https://en.wikipedia.org/wiki/OpenRC


===Epoch===

http://universe2.us/epoch.html

https://github.com/Subsentient/epoch


===finit===

http://troglobit.com/projects/finit/

===SMF (solaris)===

http://www.oracle.com/technetwork/articles/servers-storage-admin/intro-smf-basics-s11-1729181.html

===launchd (osx)===

https://en.wikipedia.org/wiki/Launchd

=Some supporting concepts and utilities=


==runlevels==

Runlevels came from sysv but were adopted 

There are usually six levels, and they usually represent specific states of the system. 

Over time, they have most usually meant something like:
* 0 shutdown/halt
* S/s/1 single-user, possibly all the same, possibly all mildly different, possibly only 1 exists
: (s is n't a runlevel internally; it tells init "go to 1 but also do this specific thing")
: used as a "everyone keep out while I fix low-level stuff" mode
* 2 multi-user mode, no networking  (or same as 3)
* 3 multi-user mode 
* 4 not used (or same as 3)
* 5 multi-user mode graphical interface   (or same as 3)
* 6 reboot


More recently it's usually simpler, something like
* 0 shutdown
* 1 single-user
* 3 graphical multi-user mode
* 6 reboot
: and everything not named aliased to 3


And since that's only two actual states, one of which is rare, modern init systems have moved away from runlevels as such (also because the sysv way of administering them is a bit involved)


...but may still imitate them. For example, in systemd you may find:
: runlevel0.target is a link to poweroff.target
: runlevel1.target is a link to rescue.target
: runlevel2.target is a link to multi-user.target
: runlevel3.target is a link to multi-user.target
: runlevel4.target is a link to multi-user.target
: runlevel5.target is a link to graphical.target
: runlevel6.target is a link to reboot.target

and e.g. booting to one via kernel parameter would be 
 systemd.unit=multi-user.target
where classically it was sticking the number of the runlevel on the end


See also:
* https://en.wikipedia.org/wiki/Runlevel

==pidfiles==

{{stub}}

Pidfiles are used as an on-filesystem reminder of which process (by its PID) is which instance of that program, and are most typically used in service management.

It's simply a text file that stores the PID  {{comment|(sometimes followed by a newline, sometimes not)}}, not unusually stored in <tt>/var/run</tt>, and not unusually with the <tt>.pid</tt> extension.

In effect, pidfiles are (filesystem-based) [[advisory locking]], though they allow more than locking - you can fairly easily:
* resolve a service to the process that currently represents it
* check whether that service is (still) running
* send signals to the the right process (reload, kill, etc.)
* allow multiple instantiations of a program/service (without ambiguity)



If a program writes its own pidfile, you often want to be able to tell it where to write it. 
Aside from avoiding hardcoded assumptions, it also means that you can move all the responsibility for this to whatever does the service management. It's also basically necessary if you want to allow multiple instantiations.




It's also bit rickety (and, in some more modern service management, not really necessary).

This all relies on the assumption that the process a pidfile points at is actually the one that we started.

The most significant possible problem in working with pidfiles is that of a '''stale pidfile''': if a pidfile was not removed when the service process quit {{comment|(or crashed, as there's often nothing watching for that case, or whether the system didn't shut down cleanly)}}, then the pidfile may not refer to a present process, or it may point to a completely unrelated process (and there usually isn't a simple way for process management to check the latter).

Stale pidfiles caused by crashes can be avoided by adding a guarding process, such as <tt>start-stop-daemon</tt>.
Regardless of the way the service quit (cleanly and removed the pidfile, or not), the wrapping program can remove the pidfile as necessary.

It's generally handiest to have the service process itself create the pidfile when it starts and remove it when it quits. A guardian program is primarily useful as a fallback for only removal.
You don't probably ''don't'' want the guarding process to create the pidfile. While it knows the PID of the process ''it'' started, that PID isn't always the one you want - consider [[forking]] daemons, apps being started though helper/wrapper scripts, and such.



To use pidfiles more robustly, consider the following:
* having the service process itself create the pidfile, for the reason just mentioned

* Use a guardian process, and note that you'll need to tell both it and the underlying app the pidfile path

* having the service process itself remove the pidfile 
** at program exit, including signaled kills (also makes management around it easier)
** preferably have it do so via an at-program-exit hook so that it will may also happen in controlled crashes

* if the pidfile a program should write to exists, either complain and quit, or check it as well as we can, and remove it when applicable (when it doesn't point to a process, or we are sure it cannot be another instance of ourselves) before starting. This avoids non-startable daemons caused by stale pidfiles.
** you can do this either in a possible manager around the service, (and/)or in the program itself. A program may be better at telling whether whether another copy of itself is running. A manager around it can often only give a warning like ''"Process might still be running. Check manually, remove /var/run/my.pid if it has stopped, and try again."''


<!--
Example Python program that, at its startup, writes a pidfile if a path to one is supplied:
<syntaxhighlight lang="python">
#!/usr/bin/python
import os,sys,atexit

#Assuming you use OptionParser to parse command line arguments
from optparse import OptionParser
parser = OptionParser()
parser.add_option("-p", dest="pidfile", help="If specified, write PID to pidfile at this path")
options, args = parser.parse_args()


if options.pidfile!=None:
    if os.access(options.pidfile,os.F_OK):
        #You could read in the PID and check what it refers to. In this example we just complain:
        raise Exception('The specified pidfile already exists.\nCould be stale; check manually, remove if it is.\n Contents: %r'%(open(options.pidfile).read()) )

    f=open(options.pidfile,'w')
    f.write( '%d\n'%os.getpid() )
    f.close()

    # make relatively sure it gets deleted
    atexit.register( lambda: os.unlink(options.pidfile) )
</syntaxhighlight >


(pidwrap, start-stop-daemon)


http://sysadvent.blogspot.com/2008/12/day-9-lock-file-practices.html

-->

==start-stop-daemon==
{{stub}}
{{inlinecode|start-stop-daemon}} is a utility which can, among other things, keep track of a [[#pidfiles|pidfile]] (created by what it starts, or created by itself), change effective user, daemonize, hand in environment variables, chroot, etc. It's a handy tool when starting services.

You can specify process(es) via --exec (full path), --pidfile, --user, and/or --name. The most specific/expressive is probably the [[pidfile]].
(Note that you can use start-stop-daemon to stop things we have not started ourselves)


Notes: 
* --start means that unless it already exists, the process is started (using --exec or --startas).
* --stop means that if a process exists, a signal (see also --signal) will be sent to it.
* return code depends on case and on use of --oknodo. Generally: 1 on error, 0 on success or when --oknodo is used.


* if the executable you specify
** fairly immediately terminates (forks off / starts something else in the background). {{comment|(note that <tt>-m</tt>, telling start-stop-daemon to create a pidfile based on the process it runs, doesn't make sense in this case. Because of this, you usually want a --pidfile argument to the process.)}}
** doesn't terminate, you can use <tt>-b</tt> to have start-stop-daemon itself be the thing that forks off, and it will be the parent of the real process. {{comment|(You can use -m in this case)}}.

Daemons that fork also mean that <tt>--exec</tt> won't match them, so some init features won't necessarily work, and unless you use one of the other features (e.g. security) you may forego start-stop-daemon.

<!--

-d change directory to this first
-->


See also:
* http://www.linuxhowtos.org/manpages/8/start-stop-daemon.htm

* https://wiki.archlinux.org/index.php/SysVinit

=tcpwrappers=
{{stub}}

'TCP wrappers' refers to a setup where a daemon (e.g. inetd, xinetd) acts as the network listener, and controls when to launch other network daemons. Basically, when it gets a connection, it runs a daemon.

One main reason was ease on admin: it lets you centralizes logging, and the logic to accept/reject on a per-host/net basis (which is the tcpd part{{verify}}). 

(Another is that if accesses to services are rare, their resource is essentially zero while they're not running)


That said, some services were always better off running their own logic.

Also, logging is often easy enough anyway,
and iptables often does fine for access control (and more centralized yet, really),

...so tcpwrappers is not very common anymore.


<!--

Using tcp wrappers requires:
* that a service is represented by a single daemon executable
* ...that can be run in response to a connection (rather than do LISTENing themselves)
* you don't mind the delay in startup (you probably would for things like databases and anything else latency-sensitive)


A daemon can choose to use tcp-wrappers.

Some can be expected to use it (e.g. sshd), 
some ''may'' have support compiled in but won't have it as their first choice (e.g. mysqld),
many others don't know about it at all, 
and many may not be alble to use it since they listen themselves.


To find out whether a program can {{comment|(which doesn't necessarily mean that it ''will'')}} use tcp-wrappers, 
see if you can make it tell you (some configuration view).
Otherwise you can do something like:
 ldd `which mysqld` | grep libwrap

-->
===configuration files===
<!--

/etc/services

/etc/inetd.conf

/etc/hosts.allow

/etc/hosts.deny

-->

===hosts.allow, hosts.deny===

Read by tcpd, so primarily really applies when using {{search|tcpwrappers}},
but there seem to be some daemons that choose to adhere to these files if they exist{{verify}}.


See also 
 man 5 hosts_access
 man 5 hosts_options

<!--

Interesting bits:
* hosts.allow is checked first (so an applicable rule there takes precedence)


Syntax:
 service : host/network : option [: option] ...
Where
* service - the name of the executable, e.g. <tt>sshd</tt>, <tt>imapd</tt>

* host/network can be one of: (this may vary between implementation{{verify}})
** full IP, e.g. 10.4.2.5
** sunbet with mask: 10.1.0.0/255.255.0.0 or 172.17.3.0/255.255.255.0
** subnet: 10.4. or 172.16.7.  (that is, subnets where the border is on an octet can use this shorthand) 
** IPv6 Addresses, e.g. [2f3f::]/10
** FQDN: foo.insecure.net
** domain insecure.net
** other hostname (as long as it resolves, e.g. via /etc/hosts)
** ALL: anyone
** LOCAL: A client that comes from the same machine or domain as the host.
** KNOWN: A client who's name and addresses can be resolved.
** PARANOID: does reverse lookup. Applies when the hostname does not match its ident/domain lookup.
** UNKNOWN: A client that cannot be resolved to anything known.

* options: 
** allow
** deny
** spawn ''command'' - 
*** will not allow/deny by themselves
** twist ''command'' - like spawn, 
** rfc931 ''[timeout]'' - does an ident lookup. The timeout option is used to limit the amount of time that the machine will wait to receive a ident response.
** nice ''[priority]'' - set process's niceness.
** banner /dir/path

<!--

http://static.closedsrc.org/articles/dn-articles/hosts_allow.html

http://jamalahmed.wordpress.com/2010/03/19/using-etchosts-allow-and-etchosts-deny-to-secure-unix/


http://en.wikipedia.org/wiki/Inetd
inetd.conf


http://en.wikipedia.org/wiki/Xinetd
xinetd.conf


tcpd
/etc/serv.access 

-->

[[Category:Unices]]
[[Category:Networking]]

=unsorted=
http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/
http://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch13s04.html
http://www.novell.com/coolsolutions/feature/15380.html





===linux===
http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/

===gentoo===
Uses a customized system.

/etc/runlevels, which is usually updated via rc-update, mentions init scripts, with symlinks that point to items in /etc/init.d/. (note the runlevels are defined in /etc/inittab)

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4