Lösung 1:
Ein Fehler, den Sie gemacht haben, war der Versuch, sshd
zu starten von Hand.
Wenn Sie stattdessen sshd
starten mit offiziellen Mitteln sollte es einfach funktionieren. Die service
Befehl weiß, wie man einen Dienst auf Ihrer Distribution richtig startet, und das sollte funktionieren:
service ssh start
Im Falle von sysv-Init-Skripten ist das alles, was Sie tun müssen. Der Grund für das Fehlen des Verzeichnisses ist, dass /var/run
ist ein symbolischer Link zu /run
und /run
ist ein tmpfs
Einhängepunkt. Das heißt bei jedem Booten /var/run
startet leer. Wenn Sie den service
verwenden Befehlen Sie die /etc/init.d/ssh
Skript wird verwendet, um sshd
zu starten aber vorher erstellt das Skript /var/run/sshd
wenn es nicht existiert.
Mit systemd
Dinge funktionieren ein bisschen anders. Es wird eine Datei namens /usr/lib/tmpfiles.d/sshd.conf
geben mit diesem Inhalt:
d /var/run/sshd 0755 root root
Während des Bootens sollte dies den /var/run/sshd
verursachen Verzeichnis erstellt werden. Was Sie benötigen, um zu überprüfen, ob die Datei vorhanden ist und den richtigen Inhalt hat. Wenn der /var/run/sshd
Verzeichnis immer noch fehlt, können Sie überprüfen, ob es erstellt wird, wenn Sie systemd-tmpfiles --create
ausführen manuell.
Lösung 2:
Daher wird /run (und /var/run, das symbolisch damit verknüpft ist) bei jedem Neustart neu erstellt. Außer dass systemd-tmpfiles dies für einige Dateien nicht tut, einschließlich (/var)/run/sshd.
Anscheinend wird dies durch ein OpenVZ-Kernel-Upgrade behoben. Aber um es jetzt tatsächlich zu beheben, bearbeiten Sie /usr/lib/tmpfiles.d/sshd.conf
und entfernen Sie /var
ab Zeile d /var/run/sshd 0755 root root
stattdessen zu lesen:
d /run/sshd 0755 root root
Und das war's..!
Und wenn der openssh-server aktualisiert wird, hoffen wir, dass sie diesen Fehler behoben haben (oder ist es wirklich ein Fehler in systemd? oder openvz??) – andernfalls könnten Sie auf das gleiche Problem stoßen.
Lösung 3:
Anscheinend wird dies behoben, wenn ein OpenVZ-Kernel 2.6.32-042stab134.7 oder neuer ausgeführt wird. Ich finde es seltsam, dass in den systemd-Startskripten irgendwie kein Fix möglich ist. Wahrscheinlich würde ein hässlicher Hack wie das automatische Erstellen von /run/sshd/ nach dem Start und dann das Starten von sshd funktionieren.
Die Ausgabe meiner systemd-tmpfiles --create
:
[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
fchownat() of /run/named failed: Invalid argument
Failed to openat(/dev/simfs): Operation not permitted
Failed to validate path /var/run/screen: Too many levels of symbolic links
Failed to validate path /var/run/sshd: Too many levels of symbolic links
Failed to validate path /var/run/sudo: Too many levels of symbolic links
Failed to validate path /var/run/sudo/ts: Too many levels of symbolic links
fchownat() of /run/systemd/netif failed: Invalid argument
fchownat() of /run/systemd/netif/links failed: Invalid argument
fchownat() of /run/systemd/netif/leases failed: Invalid argument
fchownat() of /run/log/journal failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc/system.journal failed: Invalid argument
Das Änderungsprotokoll von OpenVZ 2.6.32-042stab134.7 sagt Folgendes:
Das Ausführen von Ubuntu-Containern mit systemd 229-4ubuntu21.9 kann dazu führen, dass Dienste nicht gestartet werden, da systemd-tmpfiles den Pfad aufgrund von Symlinking-Problemen nicht validieren konnte. (PSBM-90038)
Lösung 4:
So viele Probleme ich auch mit systemd im Laufe der Jahre hatte, ich muss zugeben, dass dieses Problem stattdessen von Ansible synchronize herrührt Richtlinie.
Aus irgendeinem Grund hinterließ er nach der Bereitstellung dieses Hosts mit unseren Ansbile-Skripten das /-Verzeichnis (sowie /etc, /opt und andere), das einem Admin-Benutzer und nicht Root gehört. Nach dem Ausführen von chown
Dinge zu korrigieren, /var/run/sshd
wird jetzt beim Booten neu erstellt.
Ich schätze wirklich alle Beiträge, aber es gibt hier keinen Fehler, zumindest in dem Sinne, dass das Anwenden unangemessener Eigentumsrechte auf Stammverzeichnisse zu undefiniertem Systemverhalten führte.