Перезапуск systemctl запускает файл.service, а запуск systemctl — нет. Почему?
Похоже, я придерживаюсь мнения меньшинства по этому поводу.
Термин "сценарий" намеренно сбивает с толку, избавьтесь от него. Это программное обеспечение , которое вы там пишете, даже если вы используете исключительно bashи awk.
В команде я предпочитаю писать программное обеспечение с кодом, -процесс проверки которого осуществляется с помощью инструмента (github/gitlab/gerrit ). Это дает контроль версий в качестве бонуса. Если у вас несколько систем, добавьте инструменты непрерывного развертывания. И несколько наборов тестов, если важны целевые системы. Я не религиозен в этом, но взвешиваю выгоды и затраты.
Если у вас есть команда администраторов,самый простой vim /root/bin/x.shчаще всего является катастрофой с точки зрения -связи, связанной с изменениями, удобочитаемости кода и межсистемного -распространения. Часто одна серьезная неисправность стоит больше времени/денег, чем якобы «тяжелый» процесс.
Я предпочитаю один -вкладыш на самом деле для всего, что не заслуживает этого "тяжелого" процесса. Их можно быстро повторно использовать несколькими нажатиями клавиш, если вы знаете, как эффективно использовать историю оболочки; легко вставляется между несвязанными системами (, например. разные клиенты ).
Принципиальная разница между (не рассмотренным! )один -лайнер и рассмотренное программное обеспечение ("сценарии" ):ответственность полностью лежит на вас, когда вы выполняете один -лайнер. Вы никогда не сможете сказать себе: «Я только что нашел где-то этот -лайнер, я запускал его, не понимая, что дальше — не моя вина» -вы знали, что запускаете непроверенный и непроверенный фрагмент -из -программного обеспечения, так что это ваша вина. Убедитесь, что он достаточно мал, чтобы вы могли предвидеть результаты -, будь они прокляты, если вы этого не сделаете.
Иногда вам нужен этот упрощенный подход, и установка полосы примерно на одной строке текста хорошо работает на практике (, то есть на границе между проверенным и непроверенным кодом ). Некоторые из моих вкладышей one -выглядят ужасно длинными, но на меня они действуют эффективно. Пока я их грокаю и не пихаю на более младших коллег, все нормально. В тот момент, когда мне нужно поделиться ими -, я прохожу стандартный процесс разработки -программного обеспечения.
Проверьте systemctl status p.service. Я подозреваю, что служба active (running). Если вы попытаетесь systemctl start p.serviceили активировать его с p.timer, команда запуска будет проигнорирована.
systemctl restart p.serviceнемного отличается тем, что он остановит службу (, если работает ), а затем запустит службу. Это повлияет на устройство active (running).
Оказывается, причина такого поведения в том, что в файле.service была строка
RemainAfterExit=yes
В документации для systemd.service указано, что эта директива «особенно полезна» для однократных служб типа -. Тем не менее, он не раскрывает, что, оставив файл.service активным, файл systemd.timer не может снова запустить его.
Я понял это, запустив
sudo systemctl stop p.service
и увидев, что скрипт, указанный в директиве ExecStart= модуля, затем запускается,а затем работает
sudo systemctl start p.service
не имело никакого эффекта.
Это показывает, что модуль systemd.service (или, по крайней мере, его директива раздела [Service] ExecStart= )запускается, когда модуль останавливается (или становится неактивным ), не запускается (или становится активным ), по крайней мере, в случае Type=oneshot.
Это также показывает, что если блок systemd.service не остается активным иным образом (, в данном случае с помощью RemainAfterExit=yes ), тогда
sudo systemctl start p.service
подразумевает запуск, а затем останов устройства. Напротив,
sudo systemctl restart p.service
подразумевает остановку, а затем запуск агрегата. В этом смысле две команды являются симметричными аналогами друг друга. В обоих случаях остановка юнита активирует его.