Является ли / var / run / user / $ UID новым / var / run для файлов PID?

3527
TSG

У меня есть приложение (работает как служба от имени root), которое создает файл PID в /var/run. Но мне интересно, не является ли это сейчас лучшей практикой?

В Linux - альтернативных местах, где хранить файл pid вместо / var / run, заданный в 2012 году, спрашивающий спрашивает, следует ли вообще размещать файлы PID /var/run. Это было, однако, в значительной степени до появления systemd и перехода от операционных систем systemd от /var/runпросто к /run(как одна из systemd « Файловые системы API » и указанная в системных требованиях иерархии файлов ).

Такие вещи, как спецификация XDG Base Directory от Lennart Poettering (и других), говорят о других местах для «пользовательских несущественных файлов времени выполнения и других файловых объектов (таких как сокеты, именованные каналы,…)». Так же, как и file-hierarchyсправочная страница systemd .

И то, что я читал в другом месте, создает впечатление, что /var/run/user/$UIDэто новое стандартное расположение для таких вещей в операционных системах systemd.

  • Ответы в https://unix.stackexchange.com/questions/162900/ говорят о «файлах, используемых для запуска процессов». Предполагается, что / var / run / user / 0 будет подходящим местом, если программа запускается от имени пользователя root, но в этой публикации также говорится, что каталог удаляется / очищается, когда больше нет активных сеансов. Поскольку это услуга, действительно ли это правильное местоположение?
  • https://github.com/systemd/systemd/issues/735#issuecomment-126309537 показывает процесс, вызываемый systemd с аргументами командной строки--pid-file /run/user/1000/uzbl/event/pid
  • https://lists.debian.org/debian-user/2015/10/msg01315.html, рассылка в списке рассылки пользователей Debian, имеет одного человека, который говорит, что "Полный Freedesktop Monty" для файлов PID "указал [и] /run/userдля этого".

Можно найти много других примеров.

Так должно ли мое приложение быть изменено /var/run/user/$UID? Так как это служба (без активного сеанса), pam_systemd очистит / удалит каталог? Или $XDG_RUNTIME_DIR? Это что-то специфичное для systemd? Или это новый стандарт для всех Unices?

Какова лучшая практика в настоящее время в операционных системах systemd? В общем ли это верно и для других (не системных, но Unix-подобных) операционных систем?

4
Кто-то сумел опустить вопрос в течение 10 секунд после публикации ... не хотите объяснить, почему? TSG 8 лет назад 0
Ваш сервис работает на пользователя? Или это системный сервис? Или systemd, возможно, вообще не задействован? Daniel B 8 лет назад 1
Возможный дубликат [Linux - альтернативные места, где хранить pid файл вместо /var/run](http://superuser.com/questions/454449/linux-alternative-places-where-to-store-pid-file-instead -of-вар-бег) Xavierjazz 8 лет назад 0
Я перечислил другой ответ SU выше, но он не ссылается на / var / run / user / $ uid, поэтому я открыл этот вопрос TSG 8 лет назад 0
Учитывая теги, добавленные опрашивающим, довольно ясно, что задействован systemd. Также довольно ясно, что спрашивающий не спрашивал, каковы альтернативы, но правильно ли то, что xe сделал о новых соглашениях systemd. Есть вопрос, который должен прояснить это. JdeBP 8 лет назад 0
Это не совсем понятно, @JdeBP. Иногда теги ошибочно добавляются. Я также чувствую, что ваши правки слишком велики. Если ОП не предоставит информацию, о которой я спрашивал, на вопрос просто невозможно ответить. Daniel B 8 лет назад 0
Правки выглядят хорошо - конечно, лучше, чем я мог выразить. Теперь, надеюсь, есть не менее хороший ответ .... TSG 8 лет назад 0
«Что такое лучшая практика в настоящее время», основывает этот вопрос на мнении. И если вы удалили этот бит, то вопрос слишком широк. В любом случае это должно быть закрыто. DavidPostill 8 лет назад 0
@DanielB - программа работает как сервис (вопрос обновлен) TSG 8 лет назад 0

2 ответа на вопрос

5
Tino

Ты спрашиваешь:

Является ли / var / run / user / $ UID новым / var / run для файлов PID?

Короткий ответ - нет".

И длинный ответ по-прежнему «нет».

Или сказать это громко и ясно: традиционные файлы PID не должны идти ниже/run/user/$UID/ (AKA /var/run/user/$UID/). Храните их в обычном режиме /run/или /run/package/как обычно, так как это /run/user/$UID/служит совершенно другой цели для сервисов сеансов.

FYI:

  • Как отмечает @Daniel B, /var/runсегодня это мягкая ссылка, на которую указывает /run. Это не является специфическим systemdи может быть найдено в большинстве систем сегодня. Если вы хотите оставаться совместимым со старыми системами, есть два решения: либо оставайтесь с, /var/run/а не /run/, или попросите кого-нибудь создать мягкую ссылку /run, указывающую /var/runна такие старые системы.

  • Также обратите внимание, что /run/user/$UID/это характерно для работающих систем systemd-logind. Также это не поддерживается на старых системах.

Чтобы вдаваться в подробности для тех, кто еще не знает:

Существует 3 вида услуг: системные сервисы, пользовательские сервисы и сервисы сеансов. Все 3 типа могут работать в фоновом режиме или на переднем плане, так что это дает 6 вариантов.

Традиционные сервисы системы Foreground были запущены /etc/inittab, в настоящее время systemdони запускаются через /etc/init/. Системные службы Foreground обычно не нуждаются в файлах PID, так как они контролируются init, и могут вызываться в случае сбоя.

Фоновые системные службы традиционно запускались сценариями уровня запуска /etc/rc.d/. Обычно им нужны PID-файлы, потому что они работают в фоновом режиме, поэтому нет никакого контроля над тем, работают они или нет. PID-файлы очень подвержены ошибкам (поскольку нет гарантии, что PID останется свободным после прекращения работы службы) и используются для повторного поиска запущенных служб, когда rc-скрипт должен завершить работу службы. Эти файлы PID традиционно жили /var/runи в настоящее время живут /run/package/(или, если в пакете есть только один файл /run/package.pid).

Пользовательские сервисы - это сервисы, которые запускаются пользователем и должны жить вне сеанса пользователя. Например, сервер Minecraft или что-то вроде долгоживущего процесса запроса SAP, который запускается по требованию с помощью кратковременного сеанса. Они немного отличаются от системных служб, поскольку не могут их использовать /run/. Вместо этого их нужно использовать /tmp/или какой-нибудь каталог ниже $HOME(что проблематично, если $HOMEэто сетевой ресурс, общий для нескольких компьютеров).

Пользовательские службы Foreground иногда немного проблематичны, потому что они часто нужны tty, поэтому, если пользователь выходит из системы, он прекращает работу. Следовательно, существует множество способов оставить их в живых после того, как пользователь ушел, например nohupили screen. Но могут быть даже такие экзотические варианты, как socat tcp-connect:host:port exec:service.sh,pty.

Другим вариантом приоритетных пользовательских услуг являются задания cron, которые живут в crontabпользовательской среде. Однако эти cronjobs также могут быть фоновыми службами, например, если они не должны работать параллельно, даже если один процесс превышает время, когда выполняется следующий вызов cron.

У фоновых пользовательских сервисов та же проблема, что и у фоновых системных сервисов, поскольку они должны отслеживать, какая из них уже запущена, и контролировать уже запущенные. В прошлом это приводило к различным проблемам и исправлениям для таких вещей, как атаки через каталоги и тому подобное, из-за необходимости использовать, /tmpгде каждый может создавать файлы и каталоги.

Однако это еще не изменилось, поскольку /run/user/$UID/не предназначено для таких пользовательских услуг. Он был разработан для решения еще более сложной проблемы со службами сеансов.

Служба сеанса - это служба, которая обычно запускается при входе пользователя в систему и останавливается при выходе пользователя из системы. Это звучит просто, но набирает обороты, если для одного пользователя разрешено более одного сеанса. Трудный вопрос, который нужно решить: «когда сессия действительно заканчивается»?

Сессия начинается с первого входа в систему. Это легко понять. Но это не обязательно заканчивается, когда этот логин выходит из системы! Таким образом, сервис сеанса может быть запущен при первом входе в систему (или позже), но довольно часто необходимо продолжать работать до тех пор, пока не выйдет последний сеанс пользователя.

Услуги переднего плана обычно являются простым вариантом. Как dbusсервис X-Window, который запускается и заканчивается графическим логином. Но если вы начнете печатать гигантский PDF-файл, вы наверняка захотите, чтобы эта работа была либо успешно завершена, либо полностью завершена без остатков мусора, верно?

Сервисы сеансов такого типа либо должны продолжать работать в фоновом режиме, либо должен быть какой-то способ очистки после сбоя службы, если что-то неожиданно умирает. И вещи часто умирают в нашем мобильном мире. Подумай о своем мониторе. Вы можете подключить и отключить монитор в любое время. Нет необходимости перезагружать компьютер. Но что произойдет, если вы отключите все экраны? Ну, X11 умирает, конечно. Для некоторых пользовательских служб, запущенных в сеансе X11, это происходит неожиданно, возможно, в середине более длительной задачи.

Здесь /run/user/$UID/пригодится, так как этот каталог стирается автоматически после завершения последнего сеанса пользователя. Таким образом, службы могут доверять тому, что за пользователем будет происходить очистка всего, что хранится в /run/user/$UID/!

Таким образом, все связанные с сеансами службы должны использовать этот каталог.

Также обратите внимание, что у нас dbusсегодня. Таким образом, вам больше не нужно полагаться на PID-файлы, чтобы узнать, запущена какая-либо служба или нет. Это особенно верно для сервисов сессий, поскольку существует нечто, называемое «сессия», которое позволяет вам обрабатывать вещи немного лучше, например, использовать сегменты общей памяти или блокировать файлы, в которых можно жить /run/user/$UID/.

Вещи не легко. И, чтобы сделать его еще более сложным, есть такие вещи, как screen, tmuxили ssh(тот, кто разветвляется от оболочки), у которых есть две стороны, одна сторона - это пользовательская служба (т.е. демон), другая сторона - это служба сеанса. (tty). Хотя они обычно связаны с сеансом, это не обязательно должно происходить постоянно. Например, если вы используете sshпереадресацию портов и выходите из своей оболочки, sshостается открытым, пока не будет закрыт последний переадресованный порт. Вы можете даже открыть новые порты, пока некоторые другие остаются активными. В случае такого «двойного» сервиса может пригодиться что-то вроде файла PID, и в этом случае он даже может жить /run/user/$UID/.

(Обратите внимание, что cronего можно использовать для открытия пользовательского сеанса, поэтому, вероятно, /run/user/$UID/он доступен и для cronjobs. Но если это так, он /run/user/$UID/снова получает право на очистку после завершения всех cronjobs. Это, возможно, означает, что файлы, которые были переданы, исчезают в другом месте, в отличие от того, где они живут /tmp/, так как только перезагрузка должна безоговорочно удалять файлы там.)

Подвести итог:

Если у вас есть правильно спроектированная служба, вам никогда не понадобятся простые PID-файлы /run/user/$UID/, потому что службы сеансов (единственные, использующие этот каталог) обычно имеют более удобный способ (сеанс), чтобы сохранять контроль, даже если они работают в фоновом режиме. ,

Так что, если вы обнаружите необходимость использования PID-файла для вашей службы, очень вероятно, что вы получите что-то вроде /run/package/, /run/package.pidили /tmp/package-$UID/.

Используйте, только /run/user/$UID/если вы хотите убедиться, что файл исчезнет, ​​как только пользователь полностью выйдет из системы. Также обратите внимание, что rootпользователь не всегда вошел в систему, поэтому, скорее всего, нет /run/user/0/.

И, пожалуйста, никогда не создавайте каталоги прямо под /run/user/собой!

Надеюсь, теперь все так хорошо и понятно. Но мне есть что признаться

Я соврал тебе. И я сделал это остроумно (но без злого умысла).

Поскольку сессия ( systemd-logindс точки зрения России) не просто связана с login. Да, что-то похожее login, конечно, задействовано, но все немного сложнее:

https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/

Тем не мение:

  • Для этой публикации здесь (короткая, но неправильная история) ответом на ваш вопрос будет «нет».

  • К счастью, с длинными (и верными) сведениями о сессиях (см. Ссылку), ответ по-прежнему остается «нет».

  • Только в некоторых очень редких и очень особых случаях для очень четко определенной цели вы можете рассмотреть возможность размещения вашего файла PID /run/user/$UID/.

Хорошего дня.

0
Daniel B

The systemd.exec manual says the following about its RuntimeDirectory option:

Takes a list of directory names. If set, one or more directories by the specified names will be created below /run (for system services) or below $XDG_RUNTIME_DIR (for user services) when the unit is started, and removed when the unit is stopped.

Additionally, on the pam_systemd man page , we can find the following information about $XDG_RUNTIME_DIR (emphasis mine):

Path to a user-private user-writable directory that is bound to the user login time on the machine. It is automatically created the first time a user logs in and removed on the user's final logout.

Using these two manuals, we can deduce that $XDG_RUNTIME_DIR (/run/user/$UID on my Arch install) is not the right choice for system services. Instead, they are usually put in /run (at least on Arch and Gentoo). It may also be feasible to create them in a RuntimeDirectory as described above.

/var/run is but a symlink to /run these days.

Похожие вопросы