пользователь systemd не может получить возможность группы пользователей

Я добавил пользователя без полномочий root в группу Docker, и другая служба запустилась, когда этот пользователь без полномочий root подключился к демону Docker. но сервис не может работать. Я делаю тестовый пример для этого:

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

создать сервис systemd в тигре:

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

вот /home/tiger/connectdockerтак:

docker run -itd busybox 2> connectdocker.log

запустить этот сервис:

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

и результат:

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

но я могу подключиться к docker.sock с тигром:

tiger@# docker run -itd busybox
997e99f959cfd5500319935ec17677775da9d367d203a11efef8b42161c3ee64

чтобы доказать это, я меняю /var/run/docker.sockгруппу с докера на тигра, и сервис connectdocker может подключаться к демону docker.

изменить /var/run/docker.sock:

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

чтобы:

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

Вы должны использовать User=директиву в вашем systemdсервисе.

Пользователь =, Группа =

Установите пользователя или группу UNIX, для которых выполняются процессы, соответственно. Принимает одно имя пользователя или группы, или числовой идентификатор в качестве аргумента. Для системных служб (служб, запускаемых диспетчером системных служб, т.е. управляемых PID 1) и для пользовательских служб пользователя root (служб, управляемых экземпляром root systemd --user), по умолчанию используется значение «root», но User = может использоваться для указания другого пользователя. Для пользовательских сервисов любого другого пользователя переключение идентификационных данных пользователя не разрешено, поэтому единственно допустимым параметром является тот же пользователь, с которым работает менеджер сервисов пользователя. Если группа не установлена, используется группа по умолчанию для пользователя. Этот параметр не влияет на команды, чья командная строка имеет префикс «+».

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

Я также рекомендовал бы переместить ваш скрипт из домашнего каталога в стандартный путь, например /usr/local/binили что-то подобное.

Вы также должны обеспечить порядок ваших connectdocker.service, указав его After=docker.serviceи Requires=docker.service. Как написано, connectdocker.serviceвероятно, он пытается начать примерно в то же время docker.service, что и вам нужно подождать, docker.serviceпока он не подключится, прежде чем вы сможете подключиться к нему.

Требуется =

Настраивает зависимости требований от других модулей. Если это устройство активируется, перечисленные здесь устройства также будут активированы. Если один из других модулей будет деактивирован или его активация не удастся, этот блок будет деактивирован. Эта опция может быть указана более одного раза, или несколько единиц, разделенных пробелом, могут быть указаны в одной опции, и в этом случае будут созданы зависимости требований для всех перечисленных имен. Обратите внимание, что зависимости требований не влияют на порядок запуска или остановки служб. Это должно быть настроено независимо с опциями After = или Before =. Если юнит foo.service требует юнита bar.service, настроенного с помощью Требуется =, и не задан порядок упорядочения с помощью After = или До =, тогда оба блока будут запущены одновременно и без каких-либо задержек между ними, если активирован foo.service. Часто,

Обратите внимание, что этот тип зависимости не означает, что другой модуль всегда должен быть в активном состоянии, когда он работает. В частности: неудачные проверки условий (такие как ConditionPathExists =, ConditionPathExists =,… - см. Ниже) не приводят к сбою при запуске задания модуля с зависимостью требует =. Кроме того, некоторые типы модулей могут деактивироваться самостоятельно (например, сервисный процесс может принять решение о чистом выходе или устройство может быть отключено пользователем), что не распространяется на модули, имеющие зависимость Require =. Используйте тип зависимости BindsTo = вместе с After =, чтобы гарантировать, что юнит никогда не может быть в активном состоянии без конкретного другого юнита, также находящегося в активном состоянии (см. Ниже).

Обратите внимание, что зависимости этого типа можно также настроить вне файла конфигурации модуля, добавив символическую ссылку в каталог .requires /, сопровождающий файл модуля. Подробнее см. Выше.

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

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