Куда лучше класть socket-файлы и pid-файлы?

/run/appname/

В shm?

vodka@vodka-PC:~$ >/run/aaaaa
bash: /run/aaaaa: Permission denied

Оно опять только для root.

В интернетах пишут, что shm не предназначен для хранения файлов.

XDG_RUNTIME_DIR

При старте создай директорию /run/appname от рута и дай нужному пользователю права на запись. Но systemd это позволяет делать удобнее, конечно же.

Удваиваю $XDG_RUNTIME_DIR

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, …) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

В Ubuntu, например:

vodka@vodka-PC:~$ echo $XDG_RUNTIME_DIR
/run/user/1000
vodka@vodka-PC:~$

В то же время приложение работает от www-data, но готового каталога не существует:

vodka@vodka-PC:~$ ls -l /run/user/
total 0
drwx------ 15 vodka vodka 460 июл 26 19:16 1000
vodka@vodka-PC:~$ 

Вопросы:

1) И как сделать так, чтобы каталог под /run/user создавался автоматически при ребуте для www-data?

2) А если переменная окружения XDG_RUNTIME_DIR будет смотреть на рандомную директорию, например, /home/www-data/runtime_dir, она же не будет очищаться автоматически при ребуте, как мне надо? В чём тогда профит?

/etc/tmpfiles.d/

Там прописываешь создание нужной тебе директории с нужными правами где угодно. Я обычно /var/run/programname/ использую.

Подробности в man tmpfiles.d

То, что нужно, спасибо!

Line references path below legacy directory /var/run/, updating /var/run/paidserv/ → /run/paidserv/; please update the tmpfiles.d/ drop-in file accordingly.

Пишут, что сейчас желательно просто /run/programname использовать.

Давно уже. В генте уже несколько лет как:

$ ls -l /var/run
lrwxrwxrwx 1 root root 4 2017-05-25 04:25:24 /var/run -> /run

Располагай где угодно. Обычно где-то в /var. Но подчищай сам при старте или завершении приложения тем или иным способом, не стоит рассчитывать на ОС, тут единых механизмов особо нет. С systemd ещё можно попробовать что-то сообразить, но если ты на него завязываться не хочешь, тем более вариантов нет.

Хотя отказ от systemd звучит очень странно, тем более, что речь идёт о современных дистрибутивах. Кто вообще твой сервис будет тогда запускать?

Но подчищай сам при старте или завершении приложения тем или иным способом, не стоит рассчитывать на ОС

Что насчёт зачистки в случае крэша?

В интернете одна бабка сказала?

Да, точно. Там же сейчас симлинки эти сделали. Но суть та же. Ну и это warning, можно игнорить.

tmpfiles.d был в те времена, когда systemd ещё не придумали. Сейчас systemmd поглотил его и сделал своей частью, но сломать ещё не успел. Так что вполне можно использовать как универсальное решение.

Нужно мониторить так или иначе валидность сокетов и зачищать если что.

Кстати, вопрос: возможно ли валидировать сокет без обращения к владельцу? Формально да - try socket.open() catch

Кто вообще твой сервис будет тогда запускать?

supervisord, об этом я упомянул ещё в первом посте.

supervisor – это и есть некий аналог systemd, он появился раньше. У нас все приложения запускаются через него. Это удобнее, чем плодить кучу сервисом в systemd. Иногда количество сервисов достигает 20-40 на одном сервере. И каждый раз править unit не очень.

• у заказчика есть legacy-дистрибутивы без systemd. А supervisord работает везде.

Пруф? Что-то не припомню tmpfiles.d до systemd.

Но подчищай сам при старте или завершении приложения тем или иным способом, не стоит рассчитывать на ОС

Приложения работают на gunicorn и celery (+ celery beat). Сам переделать приложения я уж не смогу, разработчики наши вряд ли тоже будут тратить на это время. Ну и если можно проблему легко решить через tmpfiles.d,то почему бы не сделать? По мне так хорошее решение для дистрибутивов, где есть systemd.

Ты прав, я ошибся.

https://github.com/openrc/opentmpfiles

Просто я познакомился с tmpfiles.d на генту, где у меня systemd нет и никогда не было.

Подумай тогда над скриптом-обёрткой, которая будет запускать твой сервис, висеть-ждать его завершения и чистить файлы после его остановки. Это не должно быть сложно сделать и в принципе работать будет.

ждать его завершения и чистить файлы после его остановки

Как я написал в самом первом посте, при штатной остановке приложения или сервера всё само подчищается. Проблема возникает при аварийной перезагрузке, когда в ЦОД или в гипервизоре возникают проблемы.

Тогда сервер ребутается аварийно (без остановки ОС), то ничего само не подчищается.

Если приложение упало, то скрипт это увидит и подчистит. Также скрипт может монтировать tmpfs при необходимости в любом место без всяких дополнительных сервисов. Т.е. заводишь для своей программы каталог в каком-то месте, например /var/lib/myprogram и внутри него уже делаешь что душе угодно. Ну или просто при вызове скрипта, а-ля старте приложения перед вызовом самого приложения удаляешь из какой-то директории все сокеты и тд, тогда можно без tmpfs обойтись.

/var/run не подходит, так как там только root может создавать файлы и каталоги.

Создай диру лапками, выстави права на запись нужному пользователю.

/var/tmp – не уверен, что хорошая идея.

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

Создай диру лапками, выстави права на запись нужному пользователю.

Я пояснял в самом начале вопроса, что /var/run самоочищается при перезагрузке и всё содержимое, включая созданные файлы, самоликвидируется. То есть придётся каждый раз «лапками» создавать каталоги и назначать права, что нежелательно.

Поэтому остановился на варианте с tmpfiles.d, как предложил shell-script выше.

А зачем писать самописные скрипты и тратить своё время на тестирвоание, наладку и написание, если можно воспользоваться советом shell-script с tmpfiles.d? tmpfiles.d явно легче и красивее :-).

Я варианты накидываю, пускай топикстартер сам решает. Я бы тоже, наверное, воспользовался стандартными средствами, по возможности.

/var/run самоочищается при перезагрузке

Дичь какая-то…

Ну создай скрипт который будет делать

#!/bin/sh
mkdir -p /var/run/yourprog
chown -R youruser:yourgroup /var/run/yourprog
chmod 0750 /var/run/yourprog
exec yourprog $*

Я и есть топикстартер :-).