我有一個啟動 go-ethereum (geth) 的 systemd 服務，然後它會建立一個用於提供控制台的 Unix 套接字。我的問題是我的用戶無法連接到 Unix 套接字，因為雖然我的用戶和服務的用戶都在同一組中，並且創建的文件自動由服務用戶和組所有，但 geth 進程卻不會t 自動向該群組授予rw 權限。我可以透過在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套接字的任何內容都應該設定其權限。否則，希斯·羅賓遜就會搖搖欲墜。
如果守護程式服務程式建立並綁定套接字，則尋找允許您指定套接字權限的設定選項。不幸的是，您可能會發現該程式的作者可能沒有想到人們需要這樣做。
如果守護程式服務程式沒有這樣的設定機制，那麼就考慮製作守護程式服務程式收到它的控制套接字在啟動時作為一個已經打開的文件描述符，通過該LISTEN_FDS機制傳遞有關該文件描述符的信息（因為大概它是一個接受連接請求的偵聽套接字）。然後是服務管理，負責建立和綁定socket並設定其權限，其中systemd做有旋鈕。
然後設定一個Accept=No描述該套接字的 systemd 套接字單元，包括適當的ListenStream設定（假設控制介面是流套接字）和一個SocketMode=0660設定。