Services are programs or processes that run on your server at all times, usually from the time a server boots up. They are used to provide persistent support for requests and monitoring, from other processes or external clients. Examples of well known services are Apache and Postfix.
The init system is the first process that starts outside the kernel, and is generally the backend service that controls when and how services are started.
All our new installs use systemd, except for CentOS6 images that still use sysvinit. Some Ubuntu installs may still use upstart.
On a server using systemd, you might see something like this in a process list...
$ ps -eaf | grep '[s]ystemd'
root 1 0 0 07:27 ? 00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
root 343 1 0 07:28 ? 00:00:03 /usr/lib/systemd/systemd-journald
root 367 1 0 07:28 ? 00:00:00 /usr/lib/systemd/systemd-udevd
root 607 1 0 07:28 ? 00:00:00 /usr/lib/systemd/systemd-logind
Under a server running upstart, you might see these instead...
$ ps -eaf | grep '[u]pstart'
root 492 1 0 Jan02 ? 00:00:00 upstart-udev-bridge --daemon
root 1027 1 0 Jan02 ? 00:00:00 upstart-socket-bridge --daemon
Otherwise it is likely the server is using sysvinit style scripts exclusively.
There are some other service management tools that run separately from init systems, such as inetd/xinetd. Please check the relevant man pages if you are interested in those.
Sysvinit has traditionally been well tested and cared for, but it has very basic functionality. In some cases this can be desirable. Other init systems including systemd typically include backwards support for sysvinit style startup scripts.
Under systemd, services are included in the more general description of 'units'. Units can also be used to perform one off tasks on boot, and a bunch of other things. You can use the "systemctl" command with no arguments to get a list of all units systemd knows about. Any marked as "enabled" will always try to start on boot. You can also see the current state of each service from the same output.
You might want to stop a service from running, without removing the package from your system. Or restart it if the configuration has changed. Or just prevent it from starting on boot time.
# stop a service
~# systemctl stop postfix
#start a service
~# systemctl start postfix
# restart a service
~# systemctl restart postfix
# check service status
~# systemctl status postfix
# check log messages of last systemctl command
~# jounalctl -xn
You can use the enable and disable keywords to specify if a service should be activated at boot time
Older Redhat-based distros (eg CentOS6) use sysvinit. There you can examine the services configured to automatically start at boot time using chkconfig, eg:
# list services enabled under runlevel 3
~# chkconfig --list | grep 3:on
#prevent iptables from starting at boot time
~# chkconfig iptables off
#start postfix automatically at boot time
~# chkconfig postfix on
Debian/Ubuntu installs provide the "update-rc.d" command instead of "chkconfig".
To control if services are running, you can use the "service" command. Note how the service name and directive are written the other way about from systemctl
# stop a service
~# service postfix stop
#start a service
~# service postfix start
# restart a service
~# service postfix restart
The "status" keyword may also be available for some services (depending on the script used for that service).
On old Debian/Ubuntu installs, the "chkconfig" and "sysv-rc-conf" commands may also be available. Those are not installed by default but are available through the package manager.
Finally on any sysvinit system, you can always manually review which startup scripts are enabled by looking directly at the links under /etc/rcX.d folders, eg:
~# ls /etc/rc$(runlevel | cut -d' ' -f2).d/
Further SysVInit documentation (Currently the best known, may disappear)
Upstart was only seen on a few Ubuntu releases, and has been superseeded by Systemd.
Typically you use the same mechanisms as sysvinit. Upstart includes the ability to run some scripts concurrently through intelligent ordering of the startup sequence. Use "update-rc.d" to enabled or disable startup scripts. And the "service" command to start or stop them on demand.
Systemd is generally considered more capable than traditional init systems. But can be a bit more complex to manage. A few standout examples:
* can quickly start most services in parallel
* consequently enables logins early (ie delayed startup of services)
* can periodically check that services are running and restart them if not
* unit definitions are (typically) much simpler to create than service scripts
* integrates with on-demand services
* many other features
RimuHosting : Server hosting service. A Rimu Hosting Ltd business. RimuHosting services include:
© RimuHosting Ltd 2002-2024. Rimuhosting, Launchtime and the Rimuhosting logo are RimuHosting™ trademarks.
