☰

¿Hay alguna manera de verificar de manera confiable que systemd admita --user?

tag-icon • tag-icon linux ansible systemd dbus
¿Hay alguna manera de verificar de manera confiable que systemd admita --user?

Estoy intentando configurar algunos servicios de usuario usando Ansible y systemd.

En Ubuntu y RHEL 7 estoy obteniendo

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

Para Ubuntu aclaré el error, es por esto:

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

ejecute systemctl dentro de un alcance determinado del administrador de servicios, ya sea como el alcance predeterminado del sistema (sistema), el alcance del usuario actual (usuario) o el alcance de todos los usuarios (global). Para que systemd funcione con 'usuario', el usuario ejecutante debe tener su propia instancia de dbus iniciada (requisito de systemd). El proceso dbus del usuario normalmente se inicia durante el inicio de sesión normal, pero no durante la ejecución de las tareas de Ansible. De lo contrario, probablemente obtendrá el error "Error al conectarse al bus: no existe dicho archivo o directorio".

Básicamente, DBus debe iniciarse antes de systemd --userque pueda funcionar. Tampoco estoy seguro de cómo hacerlo, pero creo que puedo solucionarlo de otras maneras.

Sin embargo, el principal obstáculo en este momento es: ¿cómo verifico, genéricamente, la disponibilidad de la funcionalidad?

Lo intenté systemctl showy no hay ninguna función de "usuario" explícita. ¿La bandera es el "+PAM" de la Featureslínea? Sé que systemd usa PAM al menos parcialmente para implementarlo, no sé si es necesario para otras funciones.

¿Cómo puedo verificar que "mi" systemd sea compatible --userde manera confiable? ¿Hay algún archivo que pueda verificar? ¿Un comando? ¿Algo más? ¿Vudú de DBus?

Respuesta1

Lamentablemente, ya no puedo reproducir ese comportamiento con Ansible 2.12 en Debian 11 y no tengo otras casillas en este momento, pero mi primera solución sucia sería ignorar cualquier error y registrar el estado de respuesta y descubrir qué sucede.

- name: "Check, if user can handle user property"
  ansible.builtin.systemd:
    state: "started"
    name: "crond"
    scope: "user"
  ignore_errors: true
  changed_when: false
  register: systemd_status

- name: "Output status for debugging"
  ansible.builtin.debug:
    msg: "{{ systemd_status }}"
  when:
    - "systemd_status.failed | bool"

Cuando corras command: systemd --user status, esto te daría una respuesta concreta. Pero no puedo probarlo debido a que falta un estado de falla en Debian. También la documentación muestra un ejemplo. Pero al final, creo que a la implementación del módulo systemd le faltan algunos detalles de implementación y documentación aquí.

También hay un problema abierto en Ansible, consultehttps://github.com/ansible/ansible/issues/72674Le brinda algunas posibles soluciones al forzar una sesión prolongada.

Creo que el compromiso anterior no tiene sentido. Si el usuario no ha iniciado sesión, no hay ningún XDG_RUNTIME_DIR al que apuntar (el directorio no existe), por lo que aclarar que debería ser accesible no ayuda. Como lo menciona @ikke-t, se puede forzar una sesión persistente en systemd (por ejemplo, loginctl enable-linger), pero ansible debería manejar eso, ya sea habilitándolo automáticamente para estos casos o permitiéndolo en el módulo systemd (habilitar/deshabilitar usuario permanece).

Con trabajo manual-ansible antes de llamar a systemd:

- name: Ensure lingering enabled
  ansible.builtin.command: "loginctl enable-linger {{ user }}"
    creates: /var/lib/systemd/linger/{{ user }}

información relacionada