Systemd: создание сервиса

Introduction

In this tutorial, you learn how to use the systemctl command line utility to manage and view systemd units that are controlled by systemd on Oracle Linux 8.

systemd is the first process that starts at boot and is the final process to terminate at system shutdown. systemd is primarily used to manage system services or processes and system initialization at boot. However, systemd is also capable of handling many other tasks and functions as well including event logging, device management, user login, task scheduling, time synchronization and system boot. Many features in systemd are not fully utilized as users may be more comfortable with alternate software for these purposes or different Linux distributions may have preferred approaches to system configuration.

Different types of behaviour or functions within systemd are handled in systemd units. For example, daemon processes or system services are run as service units, while system states are usually defined as target units. Timer units can be defined to schedule tasks similarly to how you might use the system cron service and a mount unit can be used to configure a mount point similarly to how you might configure a mount point in the system fstab.

systemd is used to manage system level processes and functions, but it is also capable of managing processes running in user space. Users on a system can configure and manage their own services and systemd can even be configured to allow these services to continue running after the user has terminated their session.

Objectives

• Discover different systemd unit types
• Use systemd target units
• Learn common systemctl command syntax
• Create your own systemd timer unit in user space
• Configure systemd to allow user space processes to run after logout

Создание Сервиса в Systemd

Создайте service-файл /etc/systemd/system/foo-daemon.service (замените foo-daemon на имя вашего сервиса):

$ sudo touch /etc/systemd/system/foo-daemon.service
$ sudo chmod 664 /etc/systemd/system/foo-daemon.service

1 2	$sudo touchetcsystemdsystemfoo-daemon.service $sudo chmod664etcsystemdsystemfoo-daemon.service

Откройте файл foo-daemon.service и пропишите минимальные настройки, которые позволят управлять сервисом с помощью systemctl:

Description=Foo

ExecStart=/usr/sbin/foo-daemon

WantedBy=multi-user.target

1 2 3 4 5 6 7 8

Unit Description=Foo Service ExecStart=usrsbinfoo-daemon Install WantedBy=multi-user.target

Путь К Демону: Если вы не знаете путь к демону, попробуйте which foo-daemon.

После создания нового service-файла необходимо перезапустить systemd:

$ sudo systemctl daemon-reload

1	$sudo systemctl daemon-reload

Теперь вы можете делать start, stop, restart и проверять status сервиса:

$ sudo systemctl start foo-daemon
$ sudo systemctl stop foo-daemon
$ sudo systemctl restart foo-daemon
$ systemctl status foo-daemon

1 2 3 4

$sudo systemctl start foo-daemon $sudo systemctl stop foo-daemon $sudo systemctl restart foo-daemon $systemctl status foo-daemon

Чтобы добавить сервис в автозагрузку, необходимо активировать его:

$ sudo systemctl enable foo-daemon

1	$sudo systemctl enable foo-daemon

Чтобы проверить логи сервиса, выполните:

$ journalctl -u foo-daemon

1	$journalctl-ufoo-daemon

Управление службами

Основополагающая цель системы инициализации заключается в инициализации компонентов, которые должны запускаться после загрузки ядра Linux (традиционно называются компоненты пользовательского пространства). Система инициализации также используется для управления службами и демонами для сервера и в любой момент времени работы системы. С учетом этого мы начнем с нескольких базовых операций по управлению службами.

В целью большинства действий являются «модули», являющиеся ресурсами, которыми знает, как управлять. Модули распределяются по категориям по типу ресурса, который они представляют, и определяются файлами, известными как файлы модулей. Тип каждого модуля можно вывести из суффикса в конце файла.

Для задач по управлению службами целевым модулем будут модули службы, которые имеют файлы модулей с суффиксом . Однако для большинства команд по управлению службами вы можете не использовать суффикс , поскольку достаточно умна, чтобы знать, что вы, возможно, хотите работать со службой при использовании команд по управлению службами.

Запуск и остановка служб

Как мы уже упомянули выше, будет искать файлы для команд управления службами, так что команду можно легко ввести следующим образом:

Хотя вы можете использовать вышеуказанный формат для общего администрирования, для ясности мы будем использовать суффикс для остальных команд, чтобы предельно четко выражать цель, над которой мы работаем.

Чтобы остановить работающую в данный момент службу, можно использовать команду :

Перезапуск и перезагрузка

Чтобы перезапустить работающую службу, можно использовать команду :

Если данное приложение может перезагрузить файлы конфигурации (без перезапуска), вы можете выдать команду для инициализации этого процесса:

Если вы не уверены, есть ли у службы функция перезагрузки своей конфигурации, можно использовать команду . Это перезагрузит необходимую конфигурацию при наличии. В противном случае будет перезагружена служба для выбора новой конфигурации:

Включение и отключение служб

Указанные выше команды полезны для запуска или остановки служб во время текущего сеанса. Чтобы дать команду автоматически запускать службы при загрузке, их необходимо включить.

Для запуска службы во время загрузки используйте команду :

При этом будет создана символическая ссылка из системной копии служебного файла (обычно в или ) в месте на диске, где ищет файлы для автозапуска (обычно ; что такое цель, мы рассмотрим далее в этом руководстве).

Чтобы отключить автоматический запуск службы, можно ввести следующее:

При этом будет удалена символическая ссылка, что укажет на то, что служба не должна запускаться автоматически.

Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды, и .

Проверка статуса служб

Чтобы проверить статус службы в вашей системе, можно использовать команду :

При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.

Например, при проверке статуса сервера Nginx вы можете видеть следующий вывод:

Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.

Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду :

Это вернет текущий статус модуля, который обычно или . Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки.

Чтобы увидеть, включен ли модуль, можно использовать команду :

Это выведет информацию о том, что служба или , и снова установит код выхода на «0» или «1» в зависимости от вопроса команды.

Третья проверка заключается в проверке того, находится ли модуль в состоянии сбоя. Это означает, что была проблема, которая запустила данный модуль:

Это вернет , если он работает должным образом, или , если возникла ошибка. Если модуль был намеренно остановлен, может вернуться или . Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.

Basic setup

All the user units will be placed in . If you want to start units on first login, execute for any unit you want to be autostarted.

Tip: If you want to enable a unit for all users rather than the user executing the systemctl command, run as root. Similarly for .

Environment variables

The user instance of systemd does not inherit any of the environment variables set in places like etc. There are several ways to set environment variables for the systemd user instance:

1. For users with a directory, create a .conf file in the directory with lines of the form . Affects only that user’s user unit. See for more information.
2. Use the option in file. Affects all user units.
3. Add a drop-in config file in . Affects all user units; see
4. At any time, use or . Affects all user units started after setting the environment variables, but not the units that were already running.
5. Using the command provided by dbus. Has the same effect as , but also affects the D-Bus session. You can add this to the end of your shell initialization file.
6. For «global» environment variables for the user environment you can use the directories which are parsed by some generators. See and for more information.
7. You can also write a script which can produce environment variables that vary from user to user, this is probably the best way if you need per-user environments (this is the case for , , etc).

One variable you may want to set is .

After configuration, the command can be used to verify that the values are correct.

Service example

Create the directory and inside create a file that has the extension .conf (e.g. ):

/etc/systemd/system/user@.service.d/local.conf

Environment="PATH=/usr/lib/ccache/bin:/usr/local/bin:/usr/bin:/bin"
Environment="EDITOR=nano -c"
Environment="BROWSER=firefox"
Environment="NO_AT_BRIDGE=1"

PATH

If you customize your and plan on launching applications that make use of it from systemd units, you should make sure the modified is set on the systemd environment. Assuming you set your in , the best way to make systemd aware of your modified is by adding the following to after the variable is set:

~/.bash_profile

systemctl --user import-environment PATH

Note that this will not affect systemd services started before PATH is imported.

pam_environment

Environment variables can be made available through use of the module. See for configuration details.

Automatic start-up of systemd user instances

The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for specific user:

# loginctl enable-linger username

Warning: systemd services are not sessions, they run outside of logind. Do not use lingering to enable automatic login as it will .

Explore systemd Unit Files

After you have connected to the Oracle Linux 8 instance, you can start experimenting with the systemctl command to learn about the different units that are available.

1. Run the systemctl command to list all systemd units that are currently loaded by systemd:

   Use the Space or PgDn keys on your keyboard to page through the output.

   This command is equivalent to running:

   The output shows all currently active configuration units that systemd is managing. In the output you should notice that there are units named with different suffixes, including units named with the ‘.device’, ‘.mount’,’.service’, ‘.target’ and ‘.timer’ suffixes.

   Units are active in the sense that they are started, running, mounted or plugged in, depending on their purpose. Units can be inactive in the sense that they are stopped, unmounted or disconnected. If you want to see all units regardless of whether they are active or not, you can run:

   Output from these commands shows a selection of the different types of systemd units:

   • : Provides automount capabilities for on-demand mounting of file systems and parallelized boot-up.
   • : Controls mount points in the file system current date and time displays.
   • : Can activate services when file system path information changes.
   • : Similar to service units but manages foreign processes instead of starting them.
   • : Starts and controls daemons and the processes they consist of.
   • : Used to group units that manage system processes, such as service units and scope units, in the hierarchical cgroup tree for resource management purposes.
   • : Encapsulates local interprocess communication (IPC) or network sockets in the system, which are useful for socket-based activation.
   • : Used to group units or to provide well-known synchronization points during boot-up.
   • : Used to trigger activation of other units using timers. These provide an alternative to tasks that may have been previously managed using the cron service.
   • : Exposes kernel devices in systemd and can also be used to implement device-based activation.
   • : Encapsulates memory swap partitions or swap files.

2. Restrict the unit listing to a particular unit type by using the option.

   • Use the command to list the currently active service units on your system.

   • Run the same command again, but include the option to see all loaded units, including those that are inactive, if any.

You can repeat these commands for each of the service types that are available, so that you restrict information only to the type that you are interested in working with at any time.

Troubleshooting

Runtime directory ‘/run/user/1000’ is not owned by UID 1000, as it should

systemd: pam_systemd(systemd-user:session): Runtime directory '/run/user/1000' is not owned by UID 1000, as it should.
systemd: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set

If you see errors such as this and your login session is broken, it is possible that another system (non-user) service on your system is creating this folder. This can happen for example if you use a docker container that has a bind mount to . To fix this, you can either fix the container by removing the mount, or disable/delay the docker service.

Цели

systemd использует цели (англ. target), которые выполняют ту же задачу, что и уровни запуска (англ. runlevel), но действуют немного по-другому. Каждая цель поименована (т.е. имеет собственное имя, а не номер) и, как предполагается, предназначена для конкретных задач; возможно иметь в одно и то же время активными несколько таких целей. Некоторые цели реализованы так, что наследуют все службы других целей, добавляя к ним свои. В systemd имеются также цели, которые имитируют общие уровни запуска SystemVinit, поэтому вы можете переключаться между целевыми юнитами, используя привычную команду telinit RUNLEVEL.

Получение информации о текущих целях

При использовании systemd для этого предназначена следующая команда (заменяющая runleve):

$ systemctl list-units --type=target

Создание пользовательской цели

Уровни запуска, по которым расписаны конкретные задачи при установке ванильной Fedora по умолчанию — 0, 1, 3, 5 и 6 — имеют соответствие 1:1 с конкретными целями systemd. К сожалению, не существует хорошего способа сделать то же самое для определяемых пользователем уровней, таких как 2 и 4. Их использование предполагает, что вы создаете новый именованный целевой юнит systemd наподобие /etc/systemd/system/ваша цель, который берет за основу один из существующих уровней запуска (взгляните, например, на /usr/lib/systemd/system/graphical.target), создаете каталог /etc/systemd/system/ваша цель.wants, а после этого — символические ссылки на дополнительные службы из директории /usr/lib/systemd/system/, которые вы хотите включить при загрузке.

Таблица целей

Уровнень запуска SysV	Цель systemd	Примечания
runlevel0.target, poweroff.target	Выключить систему
1, s, single	runlevel1.target, rescue.target	Однопользовательский уровень запуска
2, 4	runlevel2.target, runlevel4.target, multi-user.target	Уровни запуска, определенные пользователем/специфичные для узла. По умолчанию соответствует уровню запуска 3
3	runlevel3.target, multi-user.target	Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть
5	runlevel5.target, graphical.target	Многопользовательский режим с графикой. Обычно эквивалентен запуску всех служб на уровне 3 и графического менеджера входа в систему
6	runlevel6.target, reboot.target	Перезагрузка
emergency	emergency.target	Аварийная оболочка

Изменение текущей цели

В systemd цели доступны посредством целевых юнитов. Вы можете изменить их командой:

# systemctl isolate graphical.target

Данная команда изменит только лишь текущую цель и не повлияет на следующую загрузку системы. Она соответствует командам Sysvinit вида telinit 3 и telinit 5.

Изменение цели загрузки по умолчанию

Стандартная цель — default.target, которая по умолчанию является псевдонимом graphical.target (примерно соответствующего прежнему уровню запуска 5). Для изменения цели загрузки по умолчанию добавьте один из следующих параметров ядра в ваш загрузчик:

• systemd.unit=multi-user.target (что примерно соответствует прежнему уровню запуска 3)
• systemd.unit=rescue.target (что примерно соответствует прежнему уровню запуска 1)

Другой способ — оставить загрузчик без изменений, а изменить целевой юнит по умолчанию — default.target. Это делается с использованием systemctl:

# systemctl set-default multi-user.target

Чтобы иметь возможность перезаписать ранее установленную default.target, используйте опцию force:

# systemctl set-default -f multi-user.target

Эффект от применения данной команды выводится через systemctl. Символическая ссылка на новый целевой юнит по умолчанию создается в директории /etc/systemd/system/default.target.

Использование целей

Одна из функций системы инициализации — перевод сервера в различные состояния. Обычно они называются уровнями запуска или уровнями выполнения. В заданный момент времени система может находиться только на одном уровне выполнения. В таблице предоставлены доступные уровни запуска

Цель	Уровень
poweroff.target
rescue.target	1
multi-user.target	2
multi-user.target	3
multi-user.target	4
graphical.target	5
reboot.target	6

В systemd вместо этого применяются цели. Цель — это точка синхронизации, которой сервер может воспользоваться для перехода в определенное состояние. К цели можно привязать службы и другие юниты, одновременно может быть активно несколько целей. Для просмотра полного списка целей в системе нужно выполнить команду:

systemctl list-units --type=target

Для просмотра цели по умолчанию, которой systemd стремится достичь при загрузке (которая, в свою очередь, запускает все файлы юнитов, составляющие дерево зависимости этой цели), выполните команду:

systemctl get-default

multi-user.target соответствует третьему уровню запуска, проверить это можно командой

runlevel

При помощи опции set-default изменить цель по умолчанию, которая будет использоваться при загрузке:

systemctl set-default graphical.target

Для просмотра привязанных к цели юнитов можно выполнить следующую команду:

systemctl list-dependencies multi-user.target

Изменять состояние системы для перехода между можно при помощи isolate (изолировать). Она останавливает все юниты, не привязанные к указанной цели. Убедитесь что изолируемая вами цель не останавливает важные службы. Например команда

systemctl isolate reboot.target

Перезагрузит вашу систему.

Юниты таймера

Таймеры systemd — файлы юнитов с суффиксом .timer. Они хранятся в тех же каталогах, что и другие , но включают в себя раздел , который определяет, как и когда таймер запускается. Существует два типа таймеров:

• Таймеры реального времени (также известные как настенные часы) запускаются в зависимости от событий календаря (как cronjobs). Для определения таких таймеров используется опция .
• Монотонные таймеры активируются после определенного промежутка времени по отношению к той или иной отправной точке. Они не сработают, если компьютер находится в режиме ожидания или выключен. Есть несколько различных монотонных таймеров, но все они имеют вид: . Обычно монотонные таймеры включают в себя и .

Подробнее см. . Синтаксис аргументов для календарных событий и временных промежутков можно найти в .

Примечание: В systemd предусмотрена цель , к которой можно привязать таймеры, запускаемые сразу после загрузки системы (подробнее см. ). Чтобы ею воспользоваться, укажите параметр в разделе файла таймера, после чего включите юнит.

Xorg and systemd

This article or section needs expansion.

There are several ways to run xorg within systemd units. Below there are two options, either by starting a new user session with an xorg process, or by launching xorg from a systemd user service.

Automatic login into Xorg without display manager

The factual accuracy of this article or section is disputed.

This option will launch a system unit that will start a user session with an xorg server and then run the usual to launch the window manager, etc. You need to have AUR installed. Set up your xinitrc as specified in the section.

The session will use its own dbus daemon, but various systemd utilities will automatically connect to the instance. Finally, enable the service for automatic login at boot. The user session lives entirely inside a systemd scope and everything in the user session should work just fine.

Xorg as a systemd user service

Alternatively, xorg can be run from within a systemd user service. This is nice since other X-related units can be made to depend on xorg, etc, but on the other hand, it has some drawbacks explained below.

provides integration with systemd in two ways:

Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges (like before 1.16), and cannot take advantage of the unprivileged mode introduced in 1.16.

This is how to launch xorg from a user service:

1. Make xorg run with root privileges for any user, by editing

/etc/X11/Xwrapper.config

allowed_users=anybody
needs_root_rights=yes

2. Add the following units to

~/.config/systemd/user/xorg@.socket

Description=Socket for xorg at display %i


ListenStream=/tmp/.X11-unix/X%i

~/.config/systemd/user/xorg@.service

Description=Xorg server at display %i

Requires=xorg@%i.socket
After=xorg@%i.socket


Type=simple
SuccessExitStatus=0 1

ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"

where } is the virtual terminal where xorg will be launched, either hard-coded in the service unit, or set in the systemd environment with

$ systemctl --user set-environment XDG_VTNR=1

Note: xorg should be launched at the same virtual terminal where the user logged in. Otherwise logind will consider the session inactive.

3. Make sure to configure the environment variable as explained .

4. Then, to enable socket activation for xorg on display 0 and tty 2 one would do:

$ systemctl --user set-environment XDG_VTNR=2     # So that xorg@.service knows which vt use
$ systemctl --user start xorg@0.socket            # Start listening on the socket for display 0

Now running any X application will launch xorg on virtual terminal 2 automatically.

The environment variable can be set in the systemd environment from , and then one could start any X application, including a window manager, as a systemd unit that depends on .

X clients as a user service

This section is being considered for removal.

With an adapted version of , one can easily have all the X clients running as a user service while leaving Xorg, the server, running in a session unprivileged.

First, put a copy of under . The copy can be named e.g. so that the original can remain accessible.

Then, replace

trap 'DISPLAY=:$tty exec "${@:-$cfgdir/sxrc}" & wait "$!"' USR1

with

trap 'systemd-run --user -u sx-client-$tty -E DISPLAY=:$tty -E XAUTHORITY="$XAUTHORITY" \
      "${@:-$cfgdir/sxrc}" & wait "$pid"' USR1

and replace

(trap '' USR1 && exec Xorg :"$tty" -keeptty vt"$tty" -noreset -auth "$XAUTHORITY") & pid=$!

with

(trap '' USR1 && exec Xorg :"$tty" -keeptty vt"$tty" -terminate -auth "$XAUTHORITY") & pid=$!

The caveat of this approach is that, if for some reason not a single X client succeeded in reaching the server, the server will need to be killed from another tty manually. Also, if e.g. needs to be run in , it will now need to be run with the option . See and for details.

One of the use cases and/or advantages of this approach is that the X clients will now be running under the user manager () and snippet (i.e. ) applied to it (e.g. ) will also be applied to the programs running in the graphical environment (including but not limited to the command-line shells running in an terminal emulator).

Получение данных о состоянии системы

Мы можем получить от сервера с systemd огромное количество информации, чтобы узнать о состоянии системы.

Например, чтобы получить список юнитов, которые systemd считает активными, нужно выполнить следующую команду (можно даже не использовать опцию list-units, потому что она подразумевается по умолчанию):

sudo systemctl list-units

Для вывода списка юнитов, которые systemd загружал или пытался загрузить в память, в том числе не активные в данный момент, нужно указать опцию —all:

sudo systemctl list-units —all

Чтобы вывести все установленные в системе юниты, в том числе те, которые systemd не пытался загрузить в память, выполните команду:

sudo systemctl list-unit-files

Представленные выше команды показывали общее состояние системы, но можно также получить информацию о состоянии отдельных юнитов.

Для просмотра обзора текущего состояния самого юнита можно воспользоваться опцией status команды systemctl. Вы увидите, активен ли юнит, получите информацию о процессе и последние записи журнала:

systemctl status nginx.service

Управление

Для того, чтобы использовать юнит-timer, включите и запустите его, как любой другой юнит (не забудьте добавить суффикс .timer). Для того, чтобы увидеть все запущенные таймеры, выполните:

$ systemctl list-timers

NEXT                          LEFT        LAST                          PASSED     UNIT                         ACTIVATES
Thu 2014-07-10 19:37:03 CEST  11h left    Wed 2014-07-09 19:37:03 CEST  12h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST  15h left    Thu 2014-07-10 00:00:13 CEST  8h ago     logrotate.timer              logrotate.service

Примечание:

• Чтобы увидеть все таймеры (в том числе и неактивные), используйте .
• Статус службы, запускаемой посредством таймера, вероятно, будет неактивным, если, конечно, она не была запущена непосредственно перед проверкой статуса.
• Если таймер рассинхронизировался, то может помочь удаление соответствующих файлов в (или ). Это файлы нулевого размера, которые отмечают последнее время запуска таймера. Если данные файлы отсутствуют, то они будут перестроены при следующем запуске соответствующего таймера.

Step 3: Create Sample Script

We will use our startup script from old articles with some tweaks to check and run systemd service as specific user and group in Linux

# cat /tmp/startup_script.sh
#!/bin/bash

if ];then
   echo "Not deepak user, exiting.."
   exit 1
fi

SCRIPT_NAME=$(basename -- "$0")

z=0
for i in {1..3}; do
    sleep 1m
    ((z++))
    echo "$SCRIPT_NAME: finished minute ${z}" >> /tmp/file
done
echo "$SCRIPT_NAME: COMPLETELY FINISHED" >> /tmp/file

So in this script we have added an explicit check for user, so unless the user executing the script is «», the script will fail to execute. If successful the script will continue to write in for 3 minutes with 1 minute interval. This will also help us make sure that the script does not exits before completing it’s defined task

Change the ownership of the script file to deepak

# chown deepak:deepak /tmp/startup_script.sh

Provide executable permission to the script

# chmod u+x /tmp/startup_script.sh

# ls -l /tmp/startup_script.sh
-r-xr--r-- 1 deepak deepak 304 Jan 17 01:58 /tmp/startup_script.sh

We will execute the script manually to make sure it works as expected

# /tmp/startup_script.sh
Not deepak user, exiting..

Management

To use a timer unit enable and start it like any other unit (remember to add the .timer suffix). To view all started timers, run:

$ systemctl list-timers

NEXT                          LEFT        LAST                          PASSED     UNIT                         ACTIVATES
Thu 2014-07-10 19:37:03 CEST  11h left    Wed 2014-07-09 19:37:03 CEST  12h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST  15h left    Thu 2014-07-10 00:00:13 CEST  8h ago     logrotate.timer              logrotate.service

Note:

• To list all timers (including inactive), use .
• The status of a service started by a timer will likely be inactive unless it is currently being triggered.
• If a timer gets out of sync, it may help to delete its file in (or in case of user timers). These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.

Check service status of individual unit file

Now the above commands will give you the status of all the unit files which are installed or available on your server. To check the status of individual file we do not want to use those commands in combination with grep and other filter utility.

Now assuming I wish to check the status of service. So I can use

# systemctl status sshd

which can give me a long list of output along with the actual status such as active, running loaded. Now these three states can also be grepped individually using the properties of a unit file

To check if a service is running or not use:

# systemctl show sshd --property=SubState
SubState=running

To check if a service is or :

# systemctl show sshd --property=ActiveState
ActiveState=active

OR you can also use:

# systemctl is-active sshd
active

To check if a service is loaded or not:

# systemctl show sshd --property=LoadState
LoadState=loaded

So we can individually grep the state of individual services using their properties. To list all the properties of a service you can use:

# systemctl show <service>

Set up systemd for User Space Units

In general, systemd is used to manage units at a system level. Users require administrator level access to the system to manage systemd units that are configured in this way. In some environments and for some unit types, users may wish to use systemd’s ability to run units within user space. For instance, users may wish to schedule tasks using systemd’s timer unit capabilities; or users may want to run specific applications or services as service units that should not require root level permission to run.

systemd starts a systemd-user process for a user at login. Units located in the following directories are processed in the following order for the user:

• : user space units provided by installed packages
• : user space units from packages that are installed in the home directory
• : global system-wide user units that should run in user space for all users
• : user created units

You can indicate to systemd that you are working in user space by using the option for any systemd command.

1. List currently available unit files for your user.

   Notice that the list of available units is significantly shorter than when you issued the same command without the option.

   The majority of these unit files, on a new system are located in . List the files in this directory to view the units located here:

2. Create a directory to host your own systemd unit files.

3. Create your own systemd service unit.

   This service unit provides three configuration sections.

   The section provides a description for the unit and any requirements. In this case, a entry defines a weak requirement for a timer unit that does not exist yet. Units that are listed as entries are run if they are available but do not prevent the parent unit from running if they are not found or fail to run.

   The section defines the behavior of this specific service unit when it is run. We rely on many default values for the available options here and only specify the line, which specifies the command that is run when the service is started. In this case, the command is run to log the system uptime and load values.

   The section defines how the service should be installed onto the system when it is enabled. Notably, the service is added as a service that is the ‘default.target’. This would mean that the service is enabled as part of the default target for this user.

4. Run the systemd unit and check its output.

   Since you have added a new unit, it is usually a good idea to reload the systemd configuration before attempting to run the service:

   Now start the new unit.

   Check that the command has run as expected. You can check that the service has run by checking its status:

   To check the output from the command that was run, use the command to view the log and specify the tag option to view logs specific to the command:

   You can enable this service so that it starts when your user first logs into the system.

   Note that the service runs when the user first logs into the system. It does not start automatically at system boot. Usually, services that run in user space terminate after the user logs out or all user sessions are terminated. Enabling persistence for user services is discussed later in this tutorial.