Previous Entry Share Next Entry
чем бить сторонников systemd
arcflashsuit
poor_sysadm
Которые что-то там звиздят про неосиляторов, преимущества и т.п.

https://blog.hqcodeshop.fi/archives/93-Handling-varrun-with-systemd.html

По сути, разработанная с нуля система оказывается набором плохо подогнанных костылей.
Нет возможности явно указать - "pre" запускаем с такими-то правами, сам демон - под такими.
Придумали странный параметр, суть которого сводится к тому, чтобы реализовать наиболее востребованный сценарий - создать каталоги под рутом, демона запустить под своим юзером.
"PermissionsStartOnly"
Очень очевидное название.

(возможен конечно и другой вариант решения - создать юнит mydaemon-chikh1 с запуском из под рута)

  • 1
Вот почему полезно иногда читать чужой код: можно посмотреть в других пакетах как это делают реальные пацаны. Я вот не буду хвастаться, я не знал правильного решения, но вот щас за 10 минут нашел (без гугла).

В статье же написан булшыт, хотя бы потому что ожидать того /var/run НЕ зачищается — нарушение FHS. Кстати, правильное решение (с tmpfiles.d) приведено там четвертым или пятым комментом.

Булшит - это когда в конфигурации предусмотрен параметр, неочевидным образом меняющий поведение.

RTFM, и все тайное станет явным :-)

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

Реальная проблема там в другом, щас напишу подробнее.

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

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

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

Из практических же соображений запихать /var/run в tmpfs является наиболее логичным решением. В этом месте в *nix вообще говоря одна большая дыра в абстракциях: куча директорий под /var должны иметь политику кэширования отличную от корневой фс. Дык вот, tmpfs наиболее полно соответствует этим практическим соображениям, но его в чистом виде нельзя, потому что запрещено FHS'ом. Поэтому в systemd сделали компромисс: подсистему, приводящую часть дерева к заранее известному виду.

Ну или авторы FHS должны были бы осознать что есть еще дополнительная абстракция "эфемерных" структур данных (которые перезагрузку в общем случае не переживают, но метаданные и общая структура их сохраняется). Но это тоже плохое решение, именно потому что лишняя абстракция. Короче, все трое хуже. Ты видишь хорошее решение? Я — нет.

PS. Здесь бы, в принципе, systemd надо было бы интегрироваться с пакетным менеджером, но боюсь, что такая интеграция привела бы только к тому, что systemd сожрал бы еще и dpkg с rpm'ом :-)

Я бы сделал в файле управления службой три части:
- prepare - создать каталоги, записать в /proc, ещё что-то, для чего сейчас используются всякие "one shot"
- keep - запуск демона, логирование, перезапуск в случае вылетания
- cleanup - операции, которые выполняем при шатдауне, помимо завершения самого процесса демона (очевидно, что он должен быть завершён автоматически)

Это прямо init-файл какой-то получится:-) От которого systemd'шники так долго бежали.

Я их вполне понимаю, они хотели простенького описания типа Exec, Depends, Provides. С этим просто работать, оно декларативно, все побочные эффекты видны навылет. Только они не учли, что дьявол в деталях и не все можно уложить в парадигму var=value. Я бы делал наверное какой-то параметризуемый скрипт, который пользователь по умолчанию не видит, но может отдельные куски перекрыть. Но тут возникают проблемы с тьюринг-полнотой этой конструкции, и вполне возможно нынешние unit-файлы это сознательная попытка этих проблем избежать. Хз, увидим позже.

Ну не init, просто три exec-а с разными юзерами и в разное время. Один перед, второй запустить и перезапускать, третий после.
От инита отличие разве что в том, что когда делали инит всяких cgroup не было, и запуск/остановку каждый монстрячил как мог.

  • 1
?

Log in