Сбой служб systemd с User= в файле службы
У меня похожая проблема с битротом на оптических носителях (в настоящее время BD -R, но я использовал тот же подход на CD -R и DVD -R ).
Существует программа под названием par2, которая генерирует данные восстановления (с использованием кодов Рида -Соломона ), так что определенное количество ошибок может быть не только обнаружено, но и исправлено. Вы настраиваете размер блока и процент избыточности (, который также является объемом требуемого дополнительного дискового пространства ). Например, если вы используете 1000 блоков и 10% избыточность, вы будете потреблять дополнительные 10% дискового пространства для 100 блоков избыточности, всего 1100 блоков. Но взамен вы можете полностью восстановить файл, если у вас есть любые 1000 неповрежденных блоков. Таким образом, пока 100 или менее блоков содержат битрот, вы можете восстановить файл.
Недостатком par2 является то, что вычисление данных для восстановления занимает некоторое время, и чем больше вы их генерируете, тем больше времени это занимает (создание 20% занимает больше времени, чем 10% ).
Другим подобным инструментом является zfec , хотя лично я им не пользовался.
Сложность заключалась в команде «su -c» в базовом скрипте, который запускал демон. Системе это не понравилось. Но поскольку скрипт должен работать и на других платформах, я модифицировал его, добавив оператор case для Linux. Поскольку systemctl в любом случае запускается под sudo, это не проблема. Теперь pid-файл может быть записан там, где мне нужно, и система выглядит счастливой.
Проблема, с которой вы столкнулись, заключается в том, что сценарии инициализации System V предполагают запуск от имени пользователя root, что является частью «спецификации» того, как они работают, и в них часто есть шаги, для выполнения которых требуется root.
В вашем случае речь шла о запуске su <userid> -c..., чтобы фактически начать работу от имени пользователя, не являющегося -root, но эта часть на самом деле не работает, если вы уже работаете под этим пользователем. Сценарии инициализации System V часто используют такие инструменты, как suили runasили аналогичные для переключения на пользователя, не являющегося -root, но эти инструменты часто не совсем подходят для этой цели(suизначально предназначались для запуска из интерактивная оболочка и будет интегрироваться с PAM, что здесь не имеет особого смысла.)
Хуже того, некоторые сценарии инициализации System V не будут иметь дело со сменой пользователя и в конечном итоге приведут к ненужному запуску демона от имени пользователя root, поскольку именно это кажется более «естественным» в сценарии инициализации System V. Это, на мой взгляд, одна из самых серьезных проблем сценариев инициализации System V, они позволяют легко сделать что-то неправильное и трудно сделать правильное.
Если вы хотите сохранить совместимость со сценарием инициализации System V, вы можете просто запустить их от имени пользователя root из systemd, так как это «протокол» при вызове таких сценариев. На самом деле, если вы хотите сохранить совместимость, вам даже не нужно отправлять модуль systemd, так как systemd сможет сгенерировать его сам с помощью генератора systemd -sysv -. Сгенерированный модуль будет очень похож на тот, который вы представили, за исключением того, что вместо этого он будет запускаться с правами root.
Если вы действительно хотите отправить модуль обслуживания systemd (, что я рекомендую вам сделать ), тогда вам следует серьезно подумать о поставке модуля, использующего Type=simple, а не forking.
Единственным условием -для этого является то, что вы можете запускать демон на переднем плане, что многие демоны могут делать, передавая флаг строки дополнительной команды -или через некоторую конфигурацию.(На самом деле для этого требуется значительно меньше усилий, поэтому, если ваш демон в настоящее время не поддерживает это, и вы контролируете источники, рассмотрите возможность добавления или запроса этой функции.)
В этот момент все, что вам нужно, это вызвать вашего демона на переднем плане из директивы ExecStart=. Вам не нужен ExecStop=, если ваш демон правильно завершает работу после получения сигнала на его уничтожение.
Вам больше не нужен pid-файл! Поскольку systemd запускает процесс-демон на переднем плане, он знает основной PID процесса-демона. Это очень важно, потому что pid-файлы часто/обычно реализуются неправильно (, они должны создаваться только после того, как демон готов к работе ), так что избавиться от этого требования довольно сложно.
Если вам нужно экспортировать определенные переменные среды перед запуском основного процесса, вы можете использовать Environment=или, возможно, EnvironmentFile=systemd, чтобы установить эти переменные. (Это будет работать нормально, пока для переменных заданы фиксированные значения, а не динамически генерируемые значения. )Если вам нужно выполнить шаги до запуска демона, вы можете использовать ExecStartPre=.
Если вам нужна большая гибкость (, например, условная установка переменных или запуск команд, установка переменных в динамические значения и т. д. ), вам следует заключить запуск в сценарий оболочки (или Python, Perl. и т. д. )и вызовите этот скрипт в ExecStart=. Сценарий установит и экспортирует любые необходимые переменные, запустит любые команды, которые необходимо выполнить, перед запуском основного демона.
Важной частью использования сценария оболочки для запуска демона является использование команды exec, чтобы заменить оболочку программой демона. Это означает, что оболочки больше не будет, а демон будет работать под тем же PID, который использовался оболочкой, поэтому systemd по-прежнему будет надежно знать основной PID демона. Конечно,демон exec, запускаемый сценарием оболочки, должен по-прежнему работать на переднем плане.
Использование сервиса Type=simpleпозволяет настраивать User=в самом модуле systemd. Кроме того, вы обычно можете применить дополнительные меры безопасности с помощью конфигурации systemd, которые могли отключить сценарий инициализации System V и предотвратить их использование. Кроме того, использование simpleвместо forkingделает эту настройку намного более надежной, а также более эффективной в системе.
Вы можете легко отправить сервисный модуль systemd сType=simpleи сценарием инициализации System V в своем пакете. Пока они имеют одинаковое имя, systemd будет предпочитать собственный сервисный модуль (, поэтому в этом случае устаревший код генератора systemd -sysv -не будет запускаться для сценария инициализации. )Таким образом, вы сохраняете совместимость с не -Linux и другими не -установками systemd, и в то же время вы можете максимально эффективно использовать современные Linux-системы с systemd.