GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Warum fehlt /var/run/sshd nach jedem Start?

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.


Linux
  1. Wie behandelt Linux mehrere aufeinanderfolgende Pfadtrennzeichen (/home////username///file)?

  2. Debian – E2fsck bei jedem Start auf /var erzwingen?

  3. Unterschied zwischen /var/log/messages, /var/log/syslog und /var/log/kern.log?

  4. Warum beginnt diese Verzögerungsschleife nach mehreren Iterationen ohne Schlaf schneller zu laufen?

  5. NGINX:connect() zu unix:/var/run/php7.0-fpm.sock fehlgeschlagen (2:Keine solche Datei oder Verzeichnis)

Django static_root in /var/www/... - keine Berechtigungen für collectstatic

Warum andere Dinge als /home auf eine separate Partition legen?

Warum haben die Verzeichnisse /home, /usr, /var usw. alle dieselbe Inode-Nummer (2)?

Wie greife ich auf Postgres zu, wenn ich eine Fehlermeldung zu /var/run/postgresql/.s.PGSQL.5432 erhalte?

Sollten Websites gemäß der empfohlenen Verwendung in /var/ oder /usr/ leben?

Erstellen Sie beim Booten ein Verzeichnis unter /var/run