☰

Gibt es eine Möglichkeit, zuverlässig zu überprüfen, ob systemd --user unterstützt?

tag-icon • tag-icon linux ansible systemd dbus
Gibt es eine Möglichkeit, zuverlässig zu überprüfen, ob systemd --user unterstützt?

Ich versuche, einige Benutzerdienste mit Ansible und systemd einzurichten.

Unter Ubuntu und RHEL 7 bekomme ich

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

Für Ubuntu habe ich den Fehler geklärt, es liegt daran:

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

Führen Sie systemctl in einem bestimmten Service-Manager-Bereich aus, entweder als Standardsystembereich (System), im Bereich des aktuellen Benutzers (Benutzer) oder im Bereich aller Benutzer (global). Damit systemd mit „Benutzer“ funktioniert, muss der ausführende Benutzer seine eigene Instanz von dbus gestartet haben (Systemd-Anforderung). Der Benutzer-dbus-Prozess wird normalerweise während der normalen Anmeldung gestartet, jedoch nicht während der Ausführung von Ansible-Aufgaben. Andernfalls erhalten Sie wahrscheinlich die Fehlermeldung „Verbindung zum Bus fehlgeschlagen: keine solche Datei oder kein solches Verzeichnis“.

Grundsätzlich muss DBus gestartet werden, bevor systemd --useres funktionieren kann. Ich bin mir auch nicht sicher, wie das geht, aber ich denke, ich kann es auf andere Weise umgehen.

Das größte Hindernis besteht derzeit jedoch darin, wie ich allgemein die Verfügbarkeit der Funktionalität überprüfen kann.

Ich habe es versucht systemctl showund es gibt keine explizite „Benutzer“-Funktion. Ist das Flag das „+PAM“ aus der FeaturesZeile? Ich weiß, dass systemd PAM zumindest teilweise verwendet, um es zu implementieren. Ich weiß nicht, ob es für andere Funktionen benötigt wird.

Wie kann ich prüfen, ob „mein“ systemd --userzuverlässig unterstützt? Gibt es eine Datei, die ich prüfen könnte? Ein Kommando? Etwas anderes? DBus-Voodoo?

Antwort1

Leider kann ich dieses Verhalten mit Ansible 2.12 auf Debian 11 nicht mehr reproduzieren und ich habe im Moment keine anderen Boxen, aber meine erste schmutzige Lösung wäre, jeden Fehler zu ignorieren, den Antwortstatus zu registrieren und herauszufinden, was passiert.

- 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"

Wenn Sie ausführen command: systemd --user status, erhalten Sie eine konkrete Antwort. Aber ich kann das nicht testen, da unter Debian ein Fehlerstatus fehlt. Die Dokumentation zeigt auch ein Beispiel. Aber letztendlich denke ich, dass der Implementierung des systemd-Moduls hier einige Implementierungsdetails und Dokumentation fehlen.

Außerdem gibt es ein offenes Problem mit Ansible, siehehttps://github.com/ansible/ansible/issues/72674Es bietet Ihnen einige mögliche Workarounds, indem es eine anhaltende Sitzung erzwingt.

Ich denke, dass das obige Commit den Kern verfehlt. Wenn der Benutzer nicht angemeldet ist, gibt es kein XDG_RUNTIME_DIR, auf das verwiesen werden kann (das Verzeichnis existiert nicht), daher hilft es nicht, klarzustellen, dass es zugänglich sein sollte. Wie von @ikke-t erwähnt, kann eine anhaltende Sitzung in systemd erzwungen werden (z. B. loginctl enable-linger ), aber Ansible sollte damit umgehen, indem es es entweder automatisch für diese Fälle aktiviert oder im systemd-Modul zulässt (Benutzer-Linger aktivieren/deaktivieren).

Mit Ansible-Manual vor dem Aufruf von systemd arbeiten:

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

verwandte Informationen