¿Existe una forma segura de eliminar automáticamente los archivos perdidos de unix-socket antes de que se ejecuten los servicios relacionados?

¿Existe una forma segura de eliminar automáticamente los archivos perdidos de unix-socket antes de que se ejecuten los servicios relacionados?

Estoy ejecutando Daphne desde el supervisor en Ubuntu 18.04 con la --unix-socketopción de vincularme a un socket Unix en lugar de a un host/puerto TCP:

command=daphne --unix-socket /home/project/run/daphne.sock project.asgi:application

daphne.sockDespués de un corte de energía, se dejó una instancia del archivo y, después de reiniciar, Daphne se negó a iniciarse, hasta que eliminé manualmente el archivo infractor.

¿Hay alguna forma de eliminar de forma segura el archivo al iniciar el sistema antes de ejecutar el supervisor?

Entiendo que este no es un problema específico de Daphne y puede afectar a otros componentes como PostgreSQL, por lo que cualquier sugerencia adecuada para limpiar archivos antes de que el supervisor o systemd inicien los servicios sería muy apreciada.

Respuesta1

Usartmpfs, por ejemplo, cree el archivo dentro /dev/shm.

Está pensado para aparecer como un sistema de archivos montado, pero almacenado enmemoria volatilen lugar de un dispositivo de almacenamiento persistente.

[énfasis mío]

En mi Debian /runtambién lo es tmpfsy puedo ver que pocas herramientas han creado sus sockets allí. De acuerdo aFHS /runes un buen lugar para un socket creado por un servicio de todo el sistema.

Datos variables en tiempo de ejecución: información sobre el sistema en ejecución desde el último inicio, por ejemplo, usuarios actualmente conectados y demonios en ejecución. Los archivos de este directorio deben eliminarse o truncarse al comienzo del proceso de inicio; pero esto no es necesario en sistemas que proporcionan este directorio como sistema de archivos temporal (tmpfs).

En mi Debian /runpertenece al root y sus bits de modo (permisos) son rwxr-xr-x. Los usuarios normales no pueden beneficiarse de ello.

/dev/shmPor otro lado rwxrwxrwt, cualquiera puede usarlo. Pero como se trata de una "tierra común" (como /tmp), surgen pocos problemas. La posibilidad de conflictos de nombres es uno de ellos. Dos usuarios pueden molestarse mutuamente incluso si sus intenciones son perfectamente inofensivas.

Entonces hay/run/user/$uid, tambien como tmpfs:

utilizado para almacenar archivos utilizados por los procesos en ejecución para ese usuario. […]
Este directorio es local del sistema y solo el usuario objetivo puede acceder a él. Por lo tanto, las aplicaciones que buscan almacenar sus archivos localmente ya no tienen que preocuparse por el control de acceso.

información relacionada