Я пишу демон-процесс для системы Debian, в C
которой используется Unix Domain Socket .
Если рабочим каталогом процесса демона является корневой каталог, существует ли идиоматический каталог для размещения сокета в файловой системе?
Я пишу демон-процесс для системы Debian, в C
которой используется Unix Domain Socket .
Если рабочим каталогом процесса демона является корневой каталог, существует ли идиоматический каталог для размещения сокета в файловой системе?
Ответы:
Они обычно находятся в /tmp
подкаталоге или в его подкаталоге. Обратите внимание, что все /tmp
объекты, подлежащие удалению при отключении, не обязательно стираются, просто имейте в виду, что это возможно , поэтому, если вы используете это, проверьте, нужно ли вам каждый раз создавать свой подкаталог. Вы захотите использовать подкаталог, если хотите ограничить доступ через разрешения, так /tmp
как он доступен для чтения всем.
/run
и /var/run
(которые могут быть символически связаны друг с другом) используются аналогичным образом, но они обычно монтируются как файловые системы tmpfs - это означает, что они создаются при загрузке и хранятся в памяти , а не на диске (поэтому не используйте это как место для выгрузки обильные данные). Для сокета времени выполнения это, вероятно, хороший выбор.
Обратите внимание, что /run
и все другие каталоги, упомянутые здесь, кроме /tmp
, доступны для записи только пользователю root. Для системного процесса это нормально, но если приложение может запускаться непривилегированным пользователем, вы либо захотите использовать /tmp
или создать где-нибудь постоянный каталог и установить для него разрешения, либо использовать местоположение в $ HOME пользователя.
Можно создать каталог в /usr/share
(или /usr/local/share
) во время установки. Каталоги и содержимое там потенциально не загружаются через ботинки, как в /tmp
или /run
. Однако, как отмечает Джорданм в комментариях, это /usr
может быть смонтировано только для чтения, и руководящие принципы иерархии файловой системы linux отражают это . Конечно, он не может быть доступен только для чтения, когда ваше приложение установлено, поэтому, если вам удобно создавать сокет там, вы можете оставить его и использовать его позже (вы все равно сможете писать в сокет, даже если файл только для чтения).
Если вам требуется постоянное место в загрузочных загрузках, которое не будет монтироваться только для чтения, /etc
это вполне безопасная ставка, поскольку она часто используется для общесистемных и повторных конфигураций. OTOH, возможно иметь системы, где устройство, лежащее в основе всей корневой файловой системы, доступно только для чтения (например, встроенные системы), с / tmp и / run на другом устройстве (возможно: tmpfs в памяти). Таким образом, две наиболее надежные стратегии выглядят так:
Установите сокет в постоянное место, когда приложение установлено.
Создайте каталог в /run
или /var/run
во время выполнения и поместите сокет туда.
Делайте то же самое только в /tmp
.
Преимущество первого состоит в том, что независимо от того, что, после установки приложения, у вас будет сокет для использования. Преимущество второго в том, что оно может быть более благоприятным для нормального программирования. Преимущество третьего состоит в том, что он не требует привилегий суперпользователя. Должно быть легко переключаться с одной реализации на другую, если вы передумаете позже.
Наконец, как показывал BatchyX , вы должны по крайней мере предложить вариант конфигурации для этого, выбрав вариант по умолчанию.
/run
или /var/run
также часто используется для корневых процессов.
/tmp
. Я буду править , что в.
/usr
может быть установлен только для чтения. Файлы никогда не должны создаваться там во время выполнения. Другие предложения хороши.
/tmp/.APPNAME/.APPSOCK
потому что демону не нужны постоянные данные.
/tmp
and /run
, заключается в том, что только root имеет права на запись /run
.