El usuario systemd no puede obtener la capacidad del grupo de usuarios

Agregué un usuario no root en el grupo docker, y otro servicio se ejecuta cuando este usuario no root se conecta al docker daemon. Pero el servicio no puede funcionar. Hago un ejemplo de prueba para esto:

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

crear un servicio systemd en tiger:

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

la /home/tiger/connectdockersiguiente manera:

docker run -itd busybox 2> connectdocker.log

iniciar este servicio:

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

y el resultado:

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

pero me puedo conectar a docker.sock con tiger:

tiger@# docker run -itd busybox
997e99f959cfd5500319935ec17677775da9d367d203a11efef8b42161c3ee64

para probar eso, cambio el /var/run/docker.sockgrupo de docker a tiger, y el servicio connectdocker puede conectarse a docker daemon.

cambio /var/run/docker.sock:

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

a:

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

Debe usar la User=directiva en su systemdservicio.

Usuario =, Grupo =

Establezca el usuario o grupo UNIX en el que se ejecutan los procesos, respectivamente. Toma un solo nombre de usuario o grupo, o una identificación numérica como argumento. Para los servicios del sistema (servicios ejecutados por el administrador de servicios del sistema, es decir, administrados por PID 1) y para los servicios de usuario del usuario raíz (servicios administrados por la instancia de root de systemd --user), el valor predeterminado es "root", pero User = may ser usado para especificar un usuario diferente. Para los servicios de usuario de cualquier otro usuario, no se permite cambiar la identidad del usuario, por lo tanto, la única configuración válida es el mismo usuario con el que se está ejecutando el administrador de servicios del usuario. Si no se establece ningún grupo, se utiliza el grupo predeterminado del usuario. Esta configuración no afecta a los comandos cuya línea de comando tiene el prefijo "+".

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

También recomendaría mover su script de un directorio de inicio a una ruta estándar, como /usr/local/bino algo similar.

También debe garantizar el pedido de su connectdocker.servicedándole el After=docker.servicey Requires=docker.service. Tal como está escrito, connectdocker.serviceprobablemente esté tratando de comenzar aproximadamente al mismo tiempo que el docker.service, y deberá esperar a docker.serviceque se active antes de poder conectarse.

Requiere =

Configura las dependencias de requisitos en otras unidades. Si esta unidad se activa, las unidades enumeradas aquí también se activarán. Si una de las otras unidades se desactiva o su activación falla, esta unidad se desactivará. Esta opción se puede especificar más de una vez o se pueden especificar varias unidades separadas por espacios en una opción, en cuyo caso se crearán dependencias de requisitos para todos los nombres enumerados. Tenga en cuenta que las dependencias de requisitos no influyen en el orden en que se inician o detienen los servicios. Esto tiene que configurarse independientemente con las opciones After = o Before =. Si una unidad foo.service requiere una unidad bar.service configurada con Requiere = y no se configura ningún pedido con After = o Before =, ambas unidades se iniciarán simultáneamente y sin demora entre ellas si foo.service está activado. A menudo,

Tenga en cuenta que este tipo de dependencia no implica que la otra unidad siempre tenga que estar en estado activo cuando esta unidad se esté ejecutando. Específicamente: las comprobaciones de condición que fallan (como ConditionPathExists =, ConditionPathExists =, ... - ver más abajo) no causan que el trabajo de inicio de una unidad con una dependencia Requiere = no falle. Además, algunos tipos de unidades pueden desactivarse por sí solos (por ejemplo, un proceso de servicio puede decidir salir limpiamente, o el usuario puede desconectar un dispositivo), que no se propaga a las unidades que tienen una dependencia Requiere =. Use el tipo de dependencia BindsTo = junto con After = para asegurarse de que una unidad nunca pueda estar en estado activo sin otra unidad específica también en estado activo (ver más abajo).

Tenga en cuenta que las dependencias de este tipo también se pueden configurar fuera del archivo de configuración de la unidad agregando un enlace simbólico a un directorio .requires / que acompaña al archivo de la unidad. Para detalles, ver arriba.

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

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