Managing Services from the Kali Linux Guide by OnWorks

Skip to content

5.4. Managing Services‌‌

Kali uses systemd as its init system, which is not only responsible for the boot sequence, but also permanently acts as a full featured service manager, starting and monitoring services.

systemd can be queried and controlled with systemctl. Without any argument, it runs the systemctl list-units command, which outputs a list of the active units. If you run systemctl status, the output shows a hierarchical overview of the running services. Comparing both out- puts, you immediately see that there are multiple kinds of units and that services are only one among them.

Each service is represented by a service unit, which is described by a service file usually shipped in

/lib/systemd/system/ (or /run/systemd/system/, or /etc/systemd/system/; they are listed by increasing order of importance, and the last one wins). Each is possibly modified by other service-name.service.d/*.conf files in the same set of directories. Those unit files are plain text files whose format is inspired by the well-known “*.ini” files of Microsoft Windows, with key

= value pairs grouped between [section] headers. Here we see a sample service file for /lib/ systemd/system/ssh.service:

[Unit]

Description=OpenBSD Secure Shell server After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]

EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process

Restart=on-failure RestartPreventExitStatus=255 Type=notify

[Install]

WantedBy=multi-user.target Alias=sshd.service

[Unit]

Description=OpenBSD Secure Shell server After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]

EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process

Restart=on-failure RestartPreventExitStatus=255 Type=notify

[Install]

WantedBy=multi-user.target Alias=sshd.service

Target units are another part of systemd’s design. They represent a desired state that you want to attain in terms of activated units (which means a running service in the case of service units). They exist mainly as a way to group dependencies on other units. When the system starts, it enables the units required to reach the default.target (which is a symlink to graphical.target, and which in turn depends on multi-user.target). So all the dependencies of those targets get activated during boot.

Such dependencies are expressed with the Wants directive on the target unit. But you don’t have to edit the target unit to add new dependencies, you can also create a symlink pointing to the

dependent unit in the /etc/systemd/system/target-name.target.wants/ directory. And this is exactly what systemctl enable foo.service does. When you enable a service, you tell systemd to add a dependency on the targets listed in the WantedBy entry of the [Install] section of the service unit file. Conversely, systemctl disable foo.service drops the same symlink and thus the dependency.

The enable and disable commands do not change anything regarding the current status of the services. They only influence what will happen at next boot. If you want to run the service immediately, you should execute systemctl start foo.service. Conversely, you can stop it with systemctl stop foo.service. You can also inspect the current status of a service with systemctl status foo.service, which usefully includes the latest lines of the associated log. After having changed the configuration of a service, you may wish to reload it or restart it: those operations are done with systemctl reload foo.service and systemctl restart foo. service respectively.