COMP075 OS2 Managing Linux Services

Services? Services are processes that start, usually when the system starts, and run, usually, until the system stops These processes often provide a service of some sort to other processes through a client-server relationship and some form of IPC (Inter Process Communication) Some, like the components of the network protocol stack, and the X windows system perform functions for the system as a whole.

Starting Services Many Different Approaches Unix System 5 (SysV), introduced in the mid 1980's, introduced a method of starting services called SysV init Until recently this was the dominant architecture used in most linux variants Others were used less widely Systemd is a new emerging standard method that is slowly being adopted by the major linux distributions We will look at both systems

Starting Services (SysV init) Services can be started manually by running their associated init script with an appropriate parameter But given the number of needed services, this needs to be automated The run levels concept makes automatic service initialization easier to configure, and a little bit flexible The init process starts first and then starts init scripts according to the default run level

Run Levels A run level is basically a directory containing softlinks into a collection of scripts /etc/init.d/rc3.d or /etc/rc3.d for run level 3 The linked scripts start or stop services for that run level The init process runs the scripts when that run level is 'entered' (or 'left') Names of scripts cause services to start or stop in a specified sequence –K03dbus –S09ntp

What Run Levels? Only really standard levels are 0, 1 and 6 –Halt, Single User and Restart Many systems also use –2 multi-user –3 multi-user with networking –5 full GUI system But it depends on the way the system is configured –In Kali and Debian the default level, 2, is a full GUI system

Start/Stop (init) Scripts init scripts are bash scripts that use a case statement to start or stop a service depending on a parameter (verb) passed to the script Most can handle start, stop and status Usually contained in /etc/init.d /etc/init.d/postgresql status –Gets the status of the postgresql service Many scripts can also handle restart /etc/init.d/rc3.d or /etc/rc3.d will contain softlinks to scripts in /etc/init.d

Linux Standard Base init Scripts According to the LSB, init scripts should always handle start, stop, restart, force-reload, and status –Restart starts if not running already –Force reload restarts if service doesn't understand reload Optionally reload and try-restart –Try-restart only restarts if service already running Scripts should behave reasonable in situations like starting a service that is already running

Configuring Run Levels Services can be added to a run level by creating softlinks to the service's init script in the /init.d/rcX.d/ directory for run level X This is not easy: must follow naming conventions –K03dbus Kills dbus –S09ntp Starts ntp –Numbers (03 09) force scripts to run in a predetermined sequence

Automatically Configuring Run Levels When packages or entire linux systems are installed: –init scripts are written to /etc/init.d and –softlinks to them are placed in the /etc/init.d/rcX.d directory This configuration is based on standard init info comments placed in the init scripts by the service developers

init info Comments Near the start of the script Delimited by the lines: ### BEGIN INIT INFO ### END INIT INFO Formatted comment lines then provide the init information –What run levels to start in –What sequence to start in

Standard init info Dependency Comments Service start sequence is based on dependencies between services specified by: Provides: service-name … Required-Start: service-name … –Must be available during start up Required-Stop: service-name … –Must be available during shut down Should-Start: service-name … Should-Stop: service-name …

Processing Dependency Comments Dependency information has no effect at run time –Is not checked Information is used to sequence the execution of the scripts by devising appropriate names for the softlinks in the run level directories during installation /etc/init.d/rc3.d/S02network –Starts the network before starting /etc/init.d/rc3.d/S03syslog

Run level init comments init info comments are used to specify the standard run levels to install the service in Default-Start: run level 1 [run level 2...] Default-Stop: run level 1 [run level 2...] Indicate run levels to start or stop the service There are also Short-Description –Limited to a single line of text. Description –Multi-line description

Manually Configuring Run Levels Creating the appropriate softlinks is not meant to be done manually chkconfig command allows for manual installation of a service in a run level chkconfig –Lists services with off/on status -l shows each run level service 35 sets service to start in levels 3 and 5 service on starts service in default levels Most distributions also have a gui for this purpose

Configuring with update-rc.d On kali the command update-rc.d performs functions like chkconfig (or you can install chkconfig) Only works if the service has not already been installed update-rc.d remove|defaults update-rc.d enable|disable S|2|3|4|5

The init Program First program run at system start up is called init It is responsible for starting services based on run levels Runs the init scripts pointed to by softlinks in /etc/init.d/rcX.d (or /etc/rcX.d) Controlled by /etc/inittab Is the parent process of all other processes

inittab Contains the default run level id:3:initdefault: Line format is id:runlevel(s):action:process id is somewhat arbitrary but conventional Action is sometimes an action type, sometimes an event that will trigger an action Process is usually a script to run

inittab examples l3:3:wait:/etc/init.d/rc 3 –When runlevel 3 is reached runs rc script with parameter '3' and waits for completion ca::ctrlaltdel:/sbin/shutdown -r -t 4 now –Runs shutdown command when Ctrl-Alt-Del is pressed 5:2345:respawn:/sbin/mingetty tty5 –Starts terminal on console 5 (/dev/tty5) in runlevels 2345 and respawns if it stops

Problems with init and Run Levels Serial execution –Services don't start in parallel making for longer boot time Large complicated init scripts Run level idea has limited flexibility Doesn't respect dependencies at init time –Only when services are installed are dependencies consulted and then only to determine startup sequence Only invoked at startup (or manually) –Limited ability to respond to events

Replacements for init Lots of not very widely used replacements have been tried Some are working: –Service Management Facility Solaris 10 and on –Launchd Mac OS X v10.4 –Upstart Ubuntu –Systemd Suse 12.1 kali 2.0 and others

systemd Well defined dependencies Dependencies allow for safe parallel starting of daemons Avoids overhead of bash scripts –Init requirements specified in declarative config files Unix domain sockets and D-Bus for IPC –Allows closer monitoring of processes Aims to replace a lot of linux components –cron, syslog, atd, udev … –Some say too many

d-bus An IPC mechanism Includes a system daemon and per user daemons User daemons enable desktop applications to communicate conveniently System daemon can be used to ease interaction with processes such as system services d-bus presents an object interface to senders and receivers using objects located in the daemons

What does systemd do? mounting your disks (checking for errors if needed), starting the firewall and other security tools, starting services connecting the network and networked filesystems starting the graphical system and the login manager which brings you to your desktop

Targets and Units Instead of run levels there are targets –When a target is started systemd starts everything the target needs –Old style run levels are represented as targets in systemd Instead of services there are units –A more general concept –Allows services to be dependent on hardware units for example –Targets are a type of unit

Types of Units Config file names are name.type –service –socket –target –device –mount –automount –timer –others

Unit Files Locations /lib/systemd/system –Installed packages /run/systemd/system –Created from templates at runtime /etc/systemd/system –Local configs, override the above These unit files are used in system mode –Like at startup Other files are used in user mode

User Unit Paths /usr/lib/systemd/user $HOME/.local/share/systemd/user /run/systemd/user /etc/systemd/user $HOME/.config/systemd/user Some others

Unit File Contents Many options Description= Documentation= Requires= RequiresOverridable= Before=, After= OnFailure=

Using sytemd Changing runlevel –systemctl isolate runlevel5.target –isolate means stop everything else Current runlevel –systemctl list-units –type=target –Only if your system uses targets to emulate run levels systemctl start sshd –Starts sshd service

Using sytemd systemctl status sshd.service service command will still work but transfers request to systemctl –service sshd status systemctl disable mysql.service systemctl enable mysql.service chkconfig still works in Suse but transfers to systemctl systemctl reboot/halt/poweroff/...

Compatibility Your system may have removed the SysVinit files from /etc/init.d –If so you can't run these scripts directly –But you shouldn't anyway –Use of service will invoke systemctl for you If you do have these scripts, the dependency comments matter and will be respected by systemd And the init scripts have to follow standards

Compatibility runlevel command may produce odd results hermes:/home/cmb # runlevel N 3 –Actually running in level 5 chkconfig may not work accurately –OK in Suse But default levels 2 3 and 4 are identical

Some Fun hermes:/home/cmb # systemd-analyze time Startup finished in 10114ms (kernel) ms (userspace) = 63087ms hermes:/home/cmb # systemd-analyze blame 16171ms ntp.service 13286ms metasploit.service 6402ms systemd-modules-load.service 3386ms ossec.service ….

References Man pages for init, inittab, chkconfig, service Man pages for systemd system – n/ n/ An intro – d/ d/ Init script – B-Core-generic/LSB-Core-generic/tocsysinit.htmlhttp://refspecs.linuxfoundation.org/LSB_4.1.0/LS B-Core-generic/LSB-Core-generic/tocsysinit.html D-bus –