systemd vs. xl2tpd

Являясь счастливым обладателем интернета по протоколу L2TP, обнаружил в openSUSE 12.3 rc2 довольно не приятное поведение системы. При гарантированно рабочем конфигурационном файле для xl2tpd, этот самый xl2tpd не работал, выдавая лишь текст из трёх строк:

2013-03-04T19:24:40.572381+06:00 linux-wwu0 xl2tpd[5382]: xl2tpd[5382]: setsockopt recvref[22]: Protocol not available
2013-03-04T19:24:40.595657+06:00 linux-wwu0 xl2tpd[5382]: xl2tpd[5382]: Using l2tp kernel support.
2013-03-04T19:24:40.596264+06:00 linux-wwu0 xl2tpd[5382]: xl2tpd[5382]: open_controlfd: Unable to open /var/run/xl2tpd/l2tp-control for reading.

Запуск сервисом соответственно тоже не удавался:

2013-03-04T19:24:40.596660+06:00 linux-wwu0 systemd[1]: xl2tpd.service: main process exited, code=exited, status=1/FAILURE
2013-03-04T19:24:40.601560+06:00 linux-wwu0 systemd[1]: Unit xl2tpd.service entered failed state

 Ранее на openSUSE 12.1 с первыми двумя сообщениями xl2tpd благополучно работал и не нужен ему был никакой l2tp-control. Но не все обновления одинаково полезны и xl2tpd в том числе в сборке для openSUSE 12.3 получил поддержку xl2tpd-control причём поддержка в непосредственно в самом демоне появилась ещё в 2011-ом году, просто более свежая версия чем 1.2.7 для oS 12.1 не собиралась. В итоге для работы демона достаточно создать этот файлик, например, так:

sudo mkdir /var/run/xl2tpd
sudo touch /var/run/xl2tpd/l2tp-control

xl2tpd благополучно проработает до следующей перезагрузки и при попытке запуска выдаст такое же сообщение о невозможности собственного запуска что и ранее.

С версии 12.3 openSUSE окончательно переходит на использование systemd, который монтирует каталоги /run, /var/run, /var/lock, и /media в tmpfs. В примечании к релизу не рекомендуется сохранять файлы, которые должны выжить при перезагрузке в эти каталоги. Незадача заключается в том, что xl2tpd об этом не знает и продолжает искать l2tp-control где он и должен быть.
Для решения проблемы пользователи Fedora, например, используют наименее очевидный способ - дополнение скрипта инициализации /etc/init.d/xl2tpd командами на создание необходимого каталога и файла. Теоретически эта схема однажды должна поломаться, когда необходимости в соблюдении остаточной совместимости со скриптами SysV больше не будет. К тому же есть более подходящий способ - с помощью средств systemd: по правилам описанным в man tmpfiles необходимо поместить в /etc/tmpfiles.d/ файл xl2tpd.conf со следующим содержанием (комментарии для пояснения строк):

# Создать каталог /var/run/xl2tpd с правами по умолчанию, если его ещё не существует.


d /var/run/xl2tpd 755 root root - -

# Создать именованный канал с правами по умолчанию, если его ещё не существует.

p /var/run/xl2tpd/l2tp-control 600 root root - -

# Не удалять каталог /var/run/xl2tpd/ и его содержимое при чистке от временных файлов.

x /var/run/xl2tpd/

После чего xl2tpd без проблем работает с systemd.

systemd и скрипт after.local

Не так давно писал про сервисы и демоны в Linux, где присутствует стартовый скрипт /etc/init.d/after.local из openSUSE.
Но пытаясь остановить bootchart с помощью этого скрипта, оказалось, что со всеми любимым systemd, after.local никакого эффекта не имеет вовсе, что мне даже подтвердили в bugzilla. Однако, jdmcdaniel3 описал как всё-таки подружить systemd и after.local.

Всё сводится к трём шагам:

1. Создать /lib/systemd/system/after-local.service со следующим содержимым:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

[Unit]
Description=/etc/init.d/after.local Compatibility
ConditionFileIsExecutable=/etc/init.d/after.local

[Service]
Type=oneshot
ExecStart=/etc/init.d/after.local
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

2. Собственно добавить after-local.service в автозагрузку, чтоб systemd понимал, что от него требуется:

systemctl enable /lib/systemd/system/after-local.service

3. Отредактировать /etc/init.d/after.local, вписав туда то, что вам нужно.
 

Измерение скорости загрузки openSUSE

В отличие от Arch Linux, использование bootchart в openSUSE даже не требуется для того, чтобы увидеть красивый график загрузки или узнать точное её время, так как этот функционал уже по умолчанию содержит в себе всеми любимый systemd.

Так, чтобы время загрузки достаточно ввести

systemd-analyze

А команда

systemd-analyze blame

покажет сколько времени забирают различные сервисы

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

systemd-analyze plot > plot.svg

При желании, полученный svg файл можно сконвертировать в png формат командой

rsvg-convert plot.svg -o plot.png

Примечание:


Мой график получился следующим:

Скорость загрузки составила 31 секунду с копейками. Стоит отметить, что в 2010-м году на компьютере с одноядерным процессором, жёстким диском PATA (IDE) и с Arch Linux на борту я получил результат загрузки в 26 секунд, который позже был улучшен до 21-й с помощью параллелизации загрузки демонов. То есть ровно на 10 секунд быстрее, чем сейчас. При этом Arch Linux сейчас активно готовится к внедрению systemd в качестве базового компонента по умолчанию... Лично для меня скорость загрузки теперь это ещё один камень в огород systemd при обещанном им турбо-ускорении.