LINUX.ORG.RU

История изменений

Исправление pfg, (текущая версия) :

неа. они все ранжированы по уровням и просто заменяют друг друга. объясняю логику.

/usr/lib/systemd - дефолтные service, идущие с пакетом программы. их редактировать нельзя ибо они при обновлении заменяются и все редактирования улетают в пустоту.

/etc/systemd - локальные service, пакет установки не может иметь service по этому пути.
можно скопировать дефолтный в /etc/systemd и отредактировать. это будет пользовательский service и он полностью заменяет service из /usr/lib/systemd, как бы он там не заменялся при обновлении пакета.

через service.d в /etc/systemd можно исправить отдельные параметры service из /usr/lib/systemd и эти изменения локальные и не сотрутся при обновлении пакета.
удобно и логично.

обнуление идет из того что тего ExecStart списочный т.е. в service таковых может быть несколько, а не один как тег User.
они полноценны и просто выполняются последовательно.
у меня в одном сервисе четыре ExecStart: в первом качается deb-пакет с тырнета, во втором устанавливается черз dpkg -i, в третьем доустанавливаются зависмости, в четвертом пакет уадляется.
и вот как этот список изменять ?? :)
применили решение в виде удаления списка через пустой «ExecStart=» и прописывания с нуля нового списка ExecStart.
вполне логично.

Исправление pfg, :

неа. они все ранжированы по уровням и просто заменяют друг друга. объясняю логику.

/usr/lib/systemd - дефолтные service, идущие с пакетом программы. их редактировать нельзя ибо они при обновлении заменяются и все редактирования улетают в пустоту.

/etc/systemd - локальные service, пакет установки не может иметь service по этому пути.
можно скопировать дефолтный в /etc/systemd и отредактировать. это будет пользовательский service и он полностью заменяет service из /usr/lib/systemd, как бы он там не заменялся при обновлении пакета.

через service.d в /etc/systemd можно исправить отдельные параметры service из /usr/lib/systemd и эти изменения локальные и не сотрутся при обновлении пакета.
удобно и логично.

обнуление идет из того что тего ExecStart списочный т.е. в service таковых может быть несколько. они полноценны и просто выполняются последовательно.
у меня в одном сервисе четыре ExecStart: в первом качается deb-пакет с тырнета, во втором устанавливается черз dpkg -i, в третьем доустанавливаются зависмости, в четвертом пакет уадляется.
и вот как этот список изменять ?? :)
применили решение в виде удаления списка через пустой «ExecStart=» и прописывания с нуля нового списка ExecStart.
вполне логично.

Исходная версия pfg, :

неа. они все ранжированы по уровням. объясняю логику.
/usr/lib/systemd - дефолтные service, идущие с пакетом программы. их редактировать нельзя ибо они при обновлении заменяются и все редактирования улетают в пустоту.

/etc/systemd - локальные service, пакет установки не может иметь service по этому пути.
можно скопировать дефолтный в /etc/systemd и отредактировать. это будет пользовательский service и он полностью заменяет service из /usr/lib/systemd, как бы он там не заменялся при обновлении пакета.

через service.d в /etc/systemd можно исправить отдельные параметры service из /usr/lib/systemd и эти изменения локальные и не сотрутся при обновлении пакета.
удобно и логично.

обнуление идет из того что тего ExecStart списочный т.е. в service таковых может быть несколько. они полноценны и просто выполняются последовательно.
у меня в одном сервисе четыре ExecStart: в первом качается deb-пакет с тырнета, во втором устанавливается черз dpkg -i, в третьем доустанавливаются зависмости, в четвертом пакет уадляется.
и вот как этот список изменять ?? :)
применили решение в виде удаления списка через пустой «ExecStart=» и прописывания с нуля нового списка ExecStart.
вполне логично.