go-ethereum(geth)을 시작한 다음 콘솔을 제공하는 Unix 소켓을 생성하는 systemd 서비스가 있습니다. 내 문제는 내 사용자와 서비스 사용자가 모두 같은 그룹에 있고 생성된 파일이 자동으로 서비스 사용자와 그룹에 의해 소유되지만 geth 프로세스가 자동으로 rw 권한을 부여하지 않기 때문에 내 사용자가 Unix 소켓에 연결할 수 없다는 것입니다. 이 그룹에. 콘솔을 사용하기 전에 터미널에서 실행 하여 이 문제를 직접 해결할 수 있지만 sudo chmod 660 /path/to/socket가능하면 이 작업을 자동으로 수행하고 싶습니다.
내가 시도한 것은 [Service]서비스 파일 섹션 에 다음과 같은 규칙을 추가하는 것입니다 ExecStartPost=/bin/chmod 660 /path/to/socket. 나는 서비스 프로세스 시작과 소켓 생성 사이에 지연이 있기 때문에 이것이 작동하지 않는다고 생각합니다. 그러면 명령 ExecStartPost이 실패하여 서비스가 종료됩니다.
이 문제를 해결하기 위해 제가 볼 수 있는 한 가지 옵션은 파일이 존재하는지 반복적으로 확인한 다음 파일이 감지되면 파일의 권한을 수정하는 스크립트를 작성하는 것입니다. 그런 다음 규칙을 로 변경할 수 있습니다 ExecStartPost=/path/to/script. 다시 말하지만, 더 간단하고 덜 강력한 솔루션은 규칙을 만드는 것입니다 ExecStartPost=/bin/bash -c "sleep 5 && /bin/chmod 660 /path/to/socket".
이 솔루션이 최선의 선택입니까, 아니면 systemd가 내 목적에 사용할 수 있는 다른/더 간단한 메커니즘을 제공합니까?
답변1
여기서의 기본 지침 원칙은 다음과 같습니다.소켓을 바인딩하는 AF_LOCAL모든 것에 는 권한이 설정되어야 합니다.. 그렇지 않으면 Heath Robinson은 불안정합니다.
데몬 서비스 프로그램이 소켓을 생성하고 바인딩하는 경우 소켓 권한을 지정할 수 있는 구성 옵션을 찾으십시오. 불행하게도 프로그램 작성자는 사람들이 이 작업을 수행해야 한다고 생각하지 않았을 수도 있습니다.
데몬 서비스 프로그램에 이러한 구성 메커니즘이 없으면 데몬 서비스 프로그램 작성을 고려하십시오.받다해당 제어 소켓은 이미 열려 있는 파일 설명자로 시작하여 LISTEN_FDS해당 메커니즘을 통해 해당 파일 설명자에 대한 정보를 전달합니다(아마도 연결 요청을 수락하는 청취 소켓이기 때문입니다). 그런 다음 소켓을 생성 및 바인딩하고 해당 권한을 설정하는 서비스 관리가 있습니다.하다손잡이가 있습니다.
Accept=No그런 다음 적절한 ListenStream설정(제어 인터페이스가 스트림 소켓이라고 가정)과 설정을 포함하여 소켓을 설명하는 시스템 소켓 장치를 설정합니다 SocketMode=0660.