Estou executando o Daphne do supervisor no Ubuntu 18.04 com a --unix-socketopção de vincular a um soquete Unix em vez de um host/porta TCP:
command=daphne --unix-socket /home/project/run/daphne.sock project.asgi:application
Após uma falha de energia, uma instância do arquivo daphne.sockfoi deixada para trás e, após a reinicialização, Daphne se recusou a iniciar, até que eu removi manualmente o arquivo incorreto.
Existe uma maneira de remover com segurança o arquivo na inicialização do sistema antes da execução do supervisor?
Entendo que este não é um problema específico do Daphne e pode afetar outros componentes como o PostgreSQL, portanto, qualquer sugestão adequada para limpar arquivos antes dos serviços iniciados pelo supervisor ou pelo systemd seria muito apreciada.
Responder1
Usartmpfs, por exemplo, crie o arquivo dentro de /dev/shm.
Pretende aparecer como um sistema de arquivos montado, mas armazenado emmemória volátilem vez de um dispositivo de armazenamento persistente.
[ênfase minha]
No meu Debian /runtambém está tmpfse posso ver que poucas ferramentas criaram seus soquetes lá. De acordo comESF /runé um bom local para um soquete criado por um serviço de todo o sistema.
Dados variáveis em tempo de execução: Informações sobre o sistema em execução desde a última inicialização, por exemplo, usuários atualmente logados e daemons em execução. Os arquivos neste diretório devem ser removidos ou truncados no início do processo de inicialização; mas isso não é necessário em sistemas que fornecem este diretório como sistema de arquivos temporário (tmpfs).
No meu Debian /runpertence ao root e seus bits de modo (permissões) são rwxr-xr-x. Os usuários normais não podem se beneficiar disso.
Por outro lado /dev/shm, rwxrwxrwtqualquer pessoa pode usá-lo. Mas como se trata de uma “terra comum” (como /tmp), surgem poucos problemas. A possibilidade de conflitos de nomes é uma delas. Dois usuários podem perturbar um ao outro mesmo que suas intenções sejam perfeitamente inofensivas.
Então há/run/user/$uid, tambem como tmpfs:
usado para armazenar arquivos usados pela execução de processos para esse usuário. […]
Este diretório é local para o sistema e acessível apenas pelo usuário alvo. Assim, os aplicativos que desejam armazenar seus arquivos localmente não precisam mais se preocupar com o controle de acesso.