systemd тред

Как убедиться, что это не зло?

Попробовать самому, вместо того, чтобы слушать умников с ЛОРа.

Изменить команду для запуска нужного демона без правки скрипта в init.d и прочитать лог работы этого демона из системного журнала за весь период до последней перезагрузки. И до кучи сделать автоматический перезапуск демона в случае его падения.

Мы боимся скриптов или просто не осилили.

На ЛОРе это уже много раз обсуждалось.

Falcon-peregrinus, ИМХО топик надо в толксы перенести.

топик надо в толксы перенести.

На самом деле, в /dev/null

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

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

Я сам из бывших хейтеров, так что пока не попробуешь, не поймёшь, зло это, или нет.

Какие реально преимущества у него перед тем же openrc?

• Дерево процессов (через CGROUP);
• Автоматический перезапуск упавшего демона (если он не oneshot);
• Oneshot-юниты (применимо: очистка диска, вайп логов);
• Логи юнитов (не нужно выцарапывать их из системного лога, хоть journalctl это и умеет без плясок и тонны пайпов);
• journalctl умеет казать логи по куче признаков, в том числе с последней перезагрузки, несколько последних загрузок, логи юнитов, логи в промежутке времени, и ещё много чего);
• Юниты можно изменять, не редактируя сам файл юнита, переписывая только ту часть, которую нужно изменить;
• Пользовательские юниты;

Пользовательские юниты что-то так и не заработали у меня

Почитать Статьи из блога леонарда под названием «systemd for administrators». Где он внятно по полочкам раскладывает о причинах создания системдэ и о решаемых им проблемах. правда статьи случайно раскиданы по блогу. Лучше искать их в гугле

Юниты можно изменять, не редактируя сам файл юнита, переписывая только ту часть, которую нужно изменить;

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

Язабан.

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

systemctl edit foo.service создаст в /etc/systemd/system каталог foo.service.d, а в нем — файл override.conf. В override.conf не обязательно копировать исходный /usr/lib/systemd/system/foo.service целиком — только те части, которые хочется заменить. Итоговый юнит будет объединением содержимого /usr/lib/systemd/system/foo.service и override.conf. Смысл таков, что /usr/lib/systemd/system/foo.service затираются при обновлениях соответствующего пакета, а override.conf — нет.

Пример:

► systemctl cat dhcpd.service
# /usr/lib/systemd/system/dhcpd.service
[Unit]
Description=DHCPv4 Server Daemon
Documentation=man:dhcpd(8) man:dhcpd.conf(5)
Wants=network-online.target
After=network-online.target
After=time-sync.target

[Service]
Type=notify
ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid
StandardError=null

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/dhcpd.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid

Здесть демону dhcpd сказано работать только с ipv4.

Понял, спасибо!!

Ну и юниты-шаблоны еще есть.

Можешь сделать юнит-файл daemon@.service и в нем использовать переменную %I в параметрах для имени конфига, например. Потом включить сервисы daemon@config1.service и daemon@config2.service.

опять новореги шкворцы себе накручивают?

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

Systemd вообще не нужен, есть два дистра без этого говна для рабов системы, один лучше другого, на выбор: Gentoo или Void.

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

Если ты «админ локалхоста» то тебе без разницы.

Это зло.

никак. сноси это bloated говно, которое везде пихают, и ставь нормальную систему инициализации!

а если серьезно, то читай маны и сам понимай, какие у него есть классные фичи, и чего ты раньше не видел в чем-нибудь другом

Пользовательские юниты что-то так и не заработали у меня

Гуёвые и не заработают, так как systemd запускает юниты ещё до сессии, и гуйня будет падать. Для этого у меня есть костылик-скрипт, который рекурсивно запускает пользовательские юниты из пользовательской (~/.config/systemd/user/*.service) диры, в системной дире (/etc/systemd/user/.*service) лежат негуёвые.

Можно пример того, о чем тут говориться?

На примере поставляемого в генте deluge.

/usr/lib/systemd/system/deluged.service:

[Unit]
Description=Deluge BitTorrent client
Documentation=man:deluged
After=network.target local-fs.target
Wants=local-fs.target

[Service]
ExecStart=/usr/bin/deluged -d -c ${DELUGED_HOME} ${DELUGED_OPTS}

[Install]
WantedBy=multi-user.target

/etc/systemd/system/deluged.service.d/00gentoo.conf:

[Service]
User=deluge
Group=deluge
UMask=002
# Environment="DELUGED_HOME=/var/lib/deluge" "DELUGED_OPTS='-u web -p 58846'"

В итоге для systemd это как один файл. Можно переопределять параметры, можно дополнять.

Гуёвые и не заработают, так как systemd запускает юниты ещё до сессии, и гуйня будет падать.

Тут немного неправильно. По-умолчанию, пользовательские юниты запускаются после запуска сессии, но работают вне этой самой сессии, и автоматически прибиваются после того как последняя сессия будет завершена. Для того, чтобы пользовательские юниты запускались при старте системы и не убивались после завершения сессий нужно включать lingering.

Всё правильно. Они запускаются до сессии (pam_systemd.so ждёт достижения то ли basic.target, то ли default.target) и вне её. Поэтому эта штука подходит только для запуска долгоживущей хрени типа dbus-server или tmux.

С другой стороны, если немного покостылить, то можно запускать и то, что должно являться частью сессии (особенно с новым polkit, где переписали active/inactive проверки).

Как вылечить systemd фобию

Понять, что это говно с нами навсегда.

А вообще, толсто.

Зачем перезапускать демона, если он вместо работы падает? И да, вот дня не проходит, чтобы не изменить команду запуска очередного демона. И каждый раз страдаю, что это не в конфиге, а, простите, в командной строке (для не понявших - «команда запуска»)

Если тебе не нужен systemd, не еспользуй. Слава Патрику! Если у тебя ферма серваков, с докерами и виртуалками, то лучше systemd.

Я смотрю, systemd обрастает простынями... Через 15 снова менять будут.

А то у нас причина падения всего одна, ага. И поведение при падении тоже настраивается.

И каждый раз страдаю, что это не в конфиге, а, простите, в командной строке

/etc/systemd/system/deluged.service.d/00gentoo.conf чем не конфиг?

Ну и про обновление и перезапись уже выше было.

★★★★★

А, ну да.

Как убедиться, что это не зло?

как убедиться что алкоголизм не зло и уверовать?

Попробовать самому, вместо того, чтобы слушать умников с ЛОРа.

1) стать достаточно компетентным чтобы сравнивать
2) сравнить все возможные решения
3) сделать неутешительный для systemd фанбоев вывод

Затем, чтобы он поднялся и проработал ещё немного. И так пока его не починят.

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

https://wiki.debian.org/Debate/initsystem

</thread>

проработал ещё немного

Ну так не работа же это. «Я откапываю, он закапывает, а тот, кто трубу кладёт, заболел».
Смысл, например, если smtp на EHLO отвечает, письмо принимает, а на роутинге падает?

просто работать, не?

В этом конкретном случае бессмысленно. Но иногда (на самом деле не иногда, а часто) бывает так, что программы падают из-за повреждения кучи, исчерпания лимита памяти и прочих недетерминистичных вещей.

из-за повреждения кучи, исчерпания лимита памяти

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

Я думал, из моего сообщения сарказм через край льёт.
Да, после падения, демон запускается как программа через strace и с записью лога.
После чего принимается решение, что делать.

Сарказма не заметил, а вот снобизмодетектор сгорел от перегрузки.