Solution 1 :
Une erreur que vous avez commise a été d'essayer de démarrer sshd à la main.
Si vous commencez plutôt sshd par des moyens officiels, cela devrait fonctionner. Le service commande sait quelle est la bonne façon de démarrer un service sur votre distribution, et cela devrait fonctionner :
service ssh start
Dans le cas des scripts d'initialisation sysv, c'est tout ce que vous devez faire. La raison pour laquelle le répertoire est manquant est que /var/run est un lien symbolique vers /run et /run est un tmpfs point de montage. Cela signifie à chaque démarrage /var/run commencera vide. Lorsque vous utilisez le service commandez le /etc/init.d/ssh le script sera utilisé pour démarrer sshd mais avant cela, le script créera /var/run/sshd s'il n'existe pas.
Avec systemd les choses fonctionnent un peu différemment. Il y aura un fichier appelé /usr/lib/tmpfiles.d/sshd.conf avec ce contenu :
d /var/run/sshd 0755 root root
Au démarrage, cela devrait provoquer le /var/run/sshd répertoire à créer. Ce dont vous avez besoin pour vérifier que le fichier existe et que son contenu est correct. Si le /var/run/sshd répertoire est toujours manquant, vous pouvez vérifier s'il est créé lorsque vous exécutez systemd-tmpfiles --create manuellement.
Solution 2 :
Donc /run (et /var/run qui y est lié) est recréé à chaque redémarrage. Sauf que systemd-tmpfiles ne le fait pas pour certains fichiers, notamment (/var)/run/sshd.
Apparemment, cela est corrigé par une mise à jour du noyau OpenVZ. Mais pour le réparer maintenant, vous modifiez /usr/lib/tmpfiles.d/sshd.conf et supprimer /var à partir de la ligne d /var/run/sshd 0755 root root à lire à la place :
d /run/sshd 0755 root root
Et c'est tout.. !
Et lorsque openssh-server sera mis à jour, nous espérons qu'ils auront corrigé ce bogue (ou est-ce vraiment un bogue dans systemd ? ou openvz ??) -- sinon vous pourriez rencontrer le même problème.
Solution 3 :
Apparemment, cela est résolu lors de l'exécution d'un noyau OpenVZ 2.6.32-042stab134.7 ou plus récent. Je trouve étrange qu'il n'y ait pas de solution possible dans les scripts de démarrage systemd d'une manière ou d'une autre. Probablement un vilain hack comme créer automatiquement /run/sshd/ après le démarrage puis démarrer sshd fonctionnerait.
La sortie de mon 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
Le changelog d'OpenVZ 2.6.32-042stab134.7 dit ceci :
L'exécution de conteneurs Ubuntu avec systemd 229-4ubuntu21.9 peut entraîner l'échec du démarrage des services car systemd-tmpfiles n'a pas pu valider le chemin en raison de problèmes de liaison symbolique. (PSBM-90038)
Solution 4 :
Pour autant de problèmes que j'ai eu avec systemd au fil des ans, je dois admettre que ce problème provient plutôt de la synchronisation d'Ansible directif.
Pour une raison quelconque, après avoir provisionné cet hôte avec nos scripts ansbile, il a laissé le répertoire / (ainsi que /etc, /opt et autres) appartenant à un utilisateur administrateur, et non root. Après avoir exécuté chown pour corriger les choses, /var/run/sshd est à nouveau créé au démarrage.
J'apprécie vraiment toutes les entrées, mais il n'y a pas de bogue ici, du moins dans le sens où l'application d'une propriété inappropriée aux répertoires racine a provoqué un comportement système indéfini.