l'utente di systemd non può ottenere l'abilità del gruppo di utenti

Ho aggiunto un utente non root nel gruppo docker e un altro servizio eseguito mentre questo utente non root si collega al daemon docker. ma il servizio non può funzionare. Faccio un esempio di prova per questo:

root@# systemctl start docker.service 
root@# gpasswd -a tiger docker

creare un servizio systemd in tigre:

[Service]
ExecStart=/home/tiger/connectdocker
Restart=always
StartLimitInterval=0
Delegate=true
KillMode=process
[Install]
WantedBy=default.target

la /home/tiger/connectdockerin questo modo:

docker run -itd busybox 2> connectdocker.log

avviare questo servizio:

tiger@# systemctl --user enable connectdocker.service
tiger@# systemctl --user start connectdocker.service

e il risultato:

Thu Jul 21 00:59:15 CST 2016
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

ma posso collegarmi a docker.sock con tiger:

tiger@# docker run -itd busybox
997e99f959cfd5500319935ec17677775da9d367d203a11efef8b42161c3ee64

per dimostrarlo, cambio il /var/run/docker.sockgruppo da docker a tiger e il servizio connectdocker può connettersi al demone docker.

cambiare /var/run/docker.sock:

ls -l /run/docker.sock
srw-rw---- 1 root docker 0 Jul 21 00:33 /run/docker.sock

per:

ls -l /run/docker.sock
srw-rw---- 1 root tiger 0 Jul 21 00:33 /run/docker.sock

Dovresti usare la User=direttiva nel tuo systemdservizio.

Utente =, Gruppo =

Impostare l'utente o il gruppo UNIX in cui i processi vengono eseguiti, rispettivamente. Accetta un singolo utente o nome di gruppo o ID numerico come argomento. Per i servizi di sistema (servizi gestiti dal gestore dei servizi di sistema, ovvero gestiti dal PID 1) e per i servizi utente dell'utente root (servizi gestiti dall'istanza root di systemd --user), il valore predefinito è "root", ma User = può essere utilizzato per specificare un altro utente. Per i servizi utente di qualsiasi altro utente, il cambio dell'identità utente non è consentito, quindi l'unica impostazione valida è lo stesso utente in cui è in esecuzione il gestore servizi dell'utente. Se non è impostato alcun gruppo, viene utilizzato il gruppo predefinito dell'utente. Questa impostazione non influisce sui comandi la cui riga di comando è preceduta da "+".

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#User=

Consiglierei anche di spostare il tuo script da una directory home a un percorso standard, simile /usr/local/bino qualcosa del genere.

Si dovrebbe anche garantire l'ordinamento del proprio connectdocker.servicedando il After=docker.servicee Requires=docker.service. Come è scritto, connectdocker.serviceprobabilmente sta provando ad avviarsi contemporaneamente a docker.service, e dovresti aspettare docker.servicedi essere attivo prima di poterti connettere.

richiede =

Configura le dipendenze dei requisiti da altre unità. Se questa unità viene attivata, verranno attivate anche le unità elencate qui. Se una delle altre unità viene disattivata o la sua attivazione non riesce, questa unità verrà disattivata. Questa opzione può essere specificata più di una volta oppure è possibile specificare più unità separate da spazio in un'opzione, nel qual caso verranno create le dipendenze dei requisiti per tutti i nomi elencati. Si noti che le dipendenze dei requisiti non influenzano l'ordine in cui i servizi vengono avviati o arrestati. Questo deve essere configurato in modo indipendente con le opzioni After = o Before =. Se un'unità foo.service richiede un'unità bar.service come configurato con Require = e nessun ordine è configurato con After = o Before =, allora entrambe le unità verranno avviate simultaneamente e senza alcun ritardo tra di loro se foo.service è attivato. Spesso,

Si noti che questo tipo di dipendenza non implica che l'altra unità deve essere sempre nello stato attivo quando questa unità è in esecuzione. In particolare: i controlli delle condizioni non riusciti (come ConditionPathExists =, ConditionPathExists =,… - vedi sotto) non causano il fallimento del processo di avvio di un'unità con una dipendenza Richiede = su di essa. Inoltre, alcuni tipi di unità possono disattivarsi da soli (ad esempio, un processo di servizio può decidere di uscire in modo pulito o un dispositivo potrebbe essere scollegato dall'utente), che non viene propagato alle unità che hanno una dipendenza Requisito =. Utilizzare il tipo di dipendenza BindsTo = insieme a After = per assicurarsi che un'unità non possa mai essere nello stato attivo senza un'altra unità specifica anche nello stato attivo (vedere di seguito).

Si noti che dipendenze di questo tipo possono anche essere configurate al di fuori del file di configurazione dell'unità aggiungendo un collegamento simbolico a una directory .requires / che accompagna il file dell'unità. Per i dettagli, vedi sopra.

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=