Я запускаю Daphne из супервизора на Ubuntu 18.04 с --unix-socketвозможностью привязки к сокету Unix, а не к хосту/порту TCP:
command=daphne --unix-socket /home/project/run/daphne.sock project.asgi:application
После сбоя питания экземпляр файла daphne.sockостался, и после перезагрузки Daphne отказалась запускаться, пока я вручную не удалил проблемный файл.
Есть ли способ безопасно удалить файл при запуске системы до запуска супервизора?
Я понимаю, что эта проблема касается не только Daphne и может затрагивать другие компоненты, такие как PostgreSQL, поэтому любые предложения по очистке файлов перед запуском служб супервизором или systemd будут высоко оценены.
решение1
Использоватьtmpfs, например, создайте файл внутри /dev/shm.
Предполагается, что он будет отображаться как смонтированная файловая система, но хранится вэнергозависимая памятьвместо постоянного запоминающего устройства.
[выделено мной]
В моем Debian /runтакже есть, tmpfsи я вижу, что несколько инструментов создали там свои сокеты. СогласноФХС /runхорошее место для сокета, созданного общесистемной службой.
Переменные данные времени выполнения: Информация о работающей системе с момента последней загрузки, например, о текущих вошедших в систему пользователях и запущенных демонах. Файлы в этом каталоге должны быть либо удалены, либо усечены в начале процесса загрузки; но это не обязательно в системах, которые предоставляют этот каталог как временную файловую систему (tmpfs).
В моем Debian /runпринадлежит root и его биты режима (разрешения) rwxr-xr-x. Обычные пользователи не могут извлечь из этого пользу.
С другой стороны , /dev/shmлюбой rwxrwxrwtможет им пользоваться. Но поскольку это "общая земля" (как и /tmp), проблем возникает немного. Возможность конфликта имен - одна из них. Два пользователя могут мешать друг другу, даже если их намерения совершенно безобидны.
Тогда есть/run/user/$uid, также как tmpfs:
используется для хранения файлов, используемых запущенными процессами для этого пользователя. […]
Этот каталог является локальным для системы и доступен только целевому пользователю. Поэтому приложениям, желающим хранить свои файлы локально, больше не нужно беспокоиться о контроле доступа.