Есть ли способ надежно проверить, что systemd поддерживает --user? - PullRequest
Новая
       71

Есть ли способ надежно проверить, что systemd поддерживает --user?

1 голос
/ 22 января 2020

Я пытаюсь настроить некоторые пользовательские службы, используя Ansible и systemd.

В Ubuntu и RHEL 7 я получаю 

# systemctl --user status
Failed to get D-Bus connection: Connection refused

Для Ubuntu я уточнил ошибку , это из-за этого:

https://docs.ansible.com/ansible/latest/modules/systemd_module.html

запустить systemctl в рамках заданной области диспетчера служб, либо в качестве области системы по умолчанию (система), область действия текущего пользователя (пользователь) или область действия всех пользователей (глобальная). Чтобы systemd работал с 'user', у исполняющего пользователя должен быть запущен собственный экземпляр dbus (требование systemd). Пользовательский процесс dbus обычно запускается во время обычного входа в систему, но не во время выполнения задач Ansible. В противном случае вы, вероятно, получите сообщение «Не удалось подключиться к шине: нет такого файла или каталога».

Обычно DBus необходимо запустить, прежде чем systemd --user сможет работать. Я тоже не уверен, как это сделать, но я могу обойти это другими способами, я думаю.

Однако сейчас главный блокировщик: как я могу проверить, как правило, наличие функциональность?

Я пробовал systemctl show, и нет явной "пользовательской" функции. Является ли флаг "+ PAM" из строки Features? Я знаю, что systemd использует PAM хотя бы частично для его реализации, я не знаю, нужен ли он для других функций.

Как я могу проверить, что "мой" systemd надежно поддерживает --user? Есть ли файл, который я могу проверить? Команда? Что-то другое? DBus вуду?

1 Ответ

1 голос
/ 22 января 2020

Дело не в том, поддерживает ли systemd --user (все разумные последние версии), а в том, выполняется ли (а) сеанс пользователя в данный момент и (б) ваш Ansible процесс можно подключиться к нему.

Решением обеих проблем является become_method: machinectl (см. Ansible документация ), но у есть проблемы в некоторых версиях systemd.

Если этот метод не работает для вас, есть обходные пути. Обычно сеанс Ansible не создает пользовательский экземпляр systemd; Вам нужно войти в систему локально, чтобы это произошло. Однако вы можете разрешить длительному всегда иметь systemd для этого пользователя.

Вторая проблема - подключение к этому экземпляру. Для этого необходимо установить переменную окружения XDG_RUNTIME_DIR; обычно до /run/user/<UID>. Это не устанавливается обычным become_method: sudo, но вы можете использовать что-то вроде этих строк, чтобы выяснить это и передать это в задачу systemd: 

- name: "Find uid of user"
  command: "id -u {{ the_user }}"
  register: the_user_uid
  check_mode: no # Run even in check mode, otherwise the playbook fails with --check.
  changed_when: false

- name: "Determine XDG_RUNTIME_DIR"
  set_fact:
    xdg_runtime_dir: "/run/user/{{ the_user_id.stdout }}"
  changed_when: false

- name: "Enable some service"
  become: true
  become_user: "{{ the_user }}"
  environment:
    XDG_RUNTIME_DIR: "{{ xdg_runtime_dir }}"
  systemd:
    user: yes
    daemon_reload: yes
    name: the_service.service
    enabled: yes
    state: started
...