Soluzione 1:
Un errore che hai fatto è stato provare ad avviare sshd a mano.
Se invece avvii sshd attraverso mezzi ufficiali dovrebbe funzionare. Il service command sa qual è il modo corretto per avviare un servizio sulla tua distribuzione, e questo dovrebbe funzionare:
service ssh start
In caso di script sysv init, è tutto ciò che devi fare. Il motivo per cui manca la directory è /var/run è un collegamento simbolico a /run e /run è un tmpfs punto di montaggio. Ciò significa che ad ogni avvio /var/run partirà vuoto. Quando usi service comanda il /etc/init.d/ssh script verrà utilizzato per avviare sshd ma prima di farlo lo script creerà /var/run/sshd se non esiste.
Con systemd le cose funzionano in modo un po' diverso. Ci sarà un file chiamato /usr/lib/tmpfiles.d/sshd.conf con questo contenuto:
d /var/run/sshd 0755 root root
Durante l'avvio questo dovrebbe causare il /var/run/sshd directory da creare. Cosa serve per verificare che il file esista e abbia il contenuto corretto. Se /var/run/sshd directory è ancora mancante, puoi verificare se viene creata quando esegui systemd-tmpfiles --create manualmente.
Soluzione 2:
Quindi /run (e /var/run collegato simbolicamente ad esso) viene ricreato ad ogni riavvio. Solo che systemd-tmpfiles non lo fa per alcuni file tra cui (/var)/run/sshd.
Apparentemente, questo è stato risolto da un aggiornamento del kernel OpenVZ. Ma per risolverlo effettivamente ora devi modificare /usr/lib/tmpfiles.d/sshd.conf e rimuovi /var dalla riga d /var/run/sshd 0755 root root da leggere invece:
d /run/sshd 0755 root root
E questo è tutto..!
E quando openssh-server viene aggiornato, speriamo che abbiano corretto questo bug (o è davvero un bug in systemd? o openvz??) -- altrimenti potresti incorrere nello stesso problema.
Soluzione 3:
Apparentemente questo viene risolto quando si esegue un kernel OpenVZ 2.6.32-042stab134.7 o successivo. Trovo strano che non ci sia alcuna soluzione possibile negli script di avvio di systemd in qualche modo. Probabilmente un brutto hack come la creazione automatica di /run/sshd/ dopo l'avvio e poi l'avvio di sshd funzionerebbe.
L'output del mio 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
Il registro delle modifiche di OpenVZ 2.6.32-042stab134.7 dice questo:
L'esecuzione di contenitori Ubuntu con systemd 229-4ubuntu21.9 potrebbe causare il mancato avvio dei servizi perché systemd-tmpfiles non è stato in grado di convalidare il percorso a causa di problemi di collegamento simbolico. (PSBM-90038)
Soluzione 4:
Per tutti i problemi che ho avuto con systemd nel corso degli anni, devo ammettere che questo problema deriva invece dalla sincronizzazione di Ansible direttiva.
Per qualche motivo, dopo aver fornito a questo host i nostri script ansbile, ha lasciato la directory / (così come /etc, /opt e altri) di proprietà di un utente amministratore e non di root. Dopo aver eseguito chown per correggere le cose, /var/run/sshd viene ora creato di nuovo all'avvio.
Apprezzo davvero tutti gli input, ma qui non c'è alcun bug, almeno nel senso che l'applicazione di una proprietà inappropriata alle directory root ha causato un comportamento di sistema indefinito.