Что значит, когда файловый дескриптор является ссылкой на канал?
@JdeBP предложил другой способ взглянуть на этот вопрос.
Restart=alwaysпроще. Легче реализовать, легче понять. Зачем нам когда-либо проверять, завершилась ли служба с кодом выхода 0 (EXIT_SUCCESS)? Возможно, в службе даже была странная ошибка / ошибка, из-за которой она завершалась с кодом выхода 0, когда этого не следовало делать.
Ответ 1 :Некоторые устройства не должны использовать Restart=always. В частности, если служба завершает работу после тайм-аута простоя.
Любопытно, что это не имело бы большого значения, если бы баг/ошибка приводила к "успешному завершению" такой службы, хотя этого делать не следовало. Поскольку тайм-аут простоя подразумевает, что служба уже настроена на автоматический запуск при поступлении нового запроса.
Однако Restart=on-failureможет использоваться для службы, которая может выходить из режима ожидания в одних конфигурациях, но не в других.systemd-networkdиспользует его по этой причине .
Ответ 2 :Практика системного администрирования может включать уничтожение или обмен сообщениями сервисных процессов для их остановки. Иногда люди используют простую команду kill, но есть и такие скрипты, как apachectl. Преимущество Restart=on-failureзаключается в том, что systemdменее рискованно рекомендовать использовать его (, как это делает справочная страница ).
Однако systemdостается в странном положении, когда они также поддерживают Restart=always, и это то, что они любят устанавливать для большинства долго -запущенных сервисов внутри проекта systemd... Это не кажется очень полезным, когда вы пытаетесь узнать об определениях службы systemd.
Вы найдете другой конец конвейера (, если процесс все еще жив )с помощью
ls -l /proc/[1-9]*/fd 2>/dev/null | grep -B 3 -F 'pipe:---'
Заимствование из этого ответа , это означает, что стандартный вывод процесса с PID <pid>был перенаправлен в канал (своего рода FIFO без представления в иерархии файловой системы ). 1155- это номер инода канала (в Linux, вы можете найти /proc/[pid]/fd/на справочной страницеproc(5)для получения дополнительной информации об этом ).
Пример:
$ cat - | less
$ pgrep cat
187873
$ ls -l /proc/187873/fd/1
l-wx------ 1 user user 64 Jul 9 22:23 /proc/187873/fd/1 -> 'pipe:[1624839]'
Стандартный вывод catперенаправляется на конец канала записи, индексный дескриптор которого равен 1624839, а стандартный ввод lessперенаправляется с конца чтения.
Если бы мы ничего не знали о процессе, подключенном к концу канала для чтения, мы могли бы искать все процессы, у которых он открыт (, но учтите, что у нас может не быть необходимых привилегий для их просмотра):
$ fuser -v /proc/187873/fd/1
USER PID ACCESS COMMAND
/proc/187873/fd/1: user 187873 F.... cat
user 187874 f.... less
Затем подтвердите, что lessон открыт (для чтения):
$ ls -l /proc/187874/fd/0
lr-x------ 1 user user 64 Jul 9 22:28 /proc/187874/fd/0 -> 'pipe:[1624839]'