관련 서비스가 실행되기 전에 길 잃은 유닉스 소켓 파일을 자동으로 제거하는 안전한 방법이 있습니까?

관련 서비스가 실행되기 전에 길 잃은 유닉스 소켓 파일을 자동으로 제거하는 안전한 방법이 있습니까?

--unix-socketTCP 호스트/포트가 아닌 Unix 소켓에 바인딩하는 옵션을 사용하여 Ubuntu 18.04의 감독자에서 Daphne을 실행하고 있습니다.

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

정전 후 파일 인스턴스가 daphne.sock남겨졌고 재부팅 후 Daphne은 문제가 되는 파일을 수동으로 제거할 때까지 시작을 거부했습니다.

감독자가 실행되기 전에 시스템 시작 시 파일을 안전하게 제거할 수 있는 방법이 있습니까?

나는 이것이 Daphne에만 국한된 문제가 아니며 PostgreSQL과 같은 다른 구성 요소에 영향을 미칠 수 있다는 것을 이해합니다. 따라서 감독자 또는 systemd가 서비스를 시작하기 전에 파일을 정리하는 데 적합한 제안은 대단히 감사하겠습니다.

답변1

사용tmpfs예를 들어 내부에 파일을 만듭니다 /dev/shm.

마운트된 파일 시스템으로 나타나도록 의도되었지만 다음 위치에 저장됩니다.휘발성 메모리영구 저장 장치 대신.

[강조 내 것]

내 데비안 /run에도tmpfs 이 생성된 도구가 거의 없는 것을 볼 수 있습니다. 에 따르면FHS /run시스템 전체 서비스에 의해 생성된 소켓을 위한 좋은 장소입니다.

런타임 변수 데이터: 마지막 부팅 이후 실행 중인 시스템에 대한 정보(예: 현재 로그인한 사용자 및 실행 중인 데몬) 이 디렉터리 아래의 파일은 부팅 프로세스 시작 시 제거되거나 잘려야 합니다. 그러나 이 디렉토리를 임시 파일 시스템(tmpfs)으로 제공하는 시스템에서는 이것이 필요하지 않습니다.

내 데비안에서는 /run루트에 속하며 해당 모드 비트(권한)는 rwxr-xr-x. 일반 사용자는 이 혜택을 누릴 수 없습니다.

반면에 /dev/shmrwxrwxrwt누구나 사용할 수 있습니다. 하지만 (예를 들어) "공유지"이기 때문에 /tmp문제가 거의 발생하지 않습니다. 이름 충돌 가능성이 그 중 하나입니다. 두 명의 사용자는 의도가 완전히 무해하더라도 서로를 방해할 수 있습니다.

그럼 거기에/run/user/$uid, 또한 다음과 같습니다 tmpfs:

해당 사용자에 대해 프로세스를 실행하는 데 사용되는 파일을 저장하는 데 사용됩니다. [...]
이 디렉토리는 시스템에 로컬이며 대상 사용자만 액세스할 수 있습니다. 따라서 파일을 로컬에 저장하려는 애플리케이션은 더 이상 액세스 제어에 대해 걱정할 필요가 없습니다.

관련 정보