Solusi 1:
Satu kesalahan yang Anda lakukan adalah mencoba memulai sshd dengan tangan.
Jika Anda malah memulai sshd melalui cara resmi itu seharusnya bekerja. service perintah tahu apa cara yang benar untuk memulai layanan pada distribusi Anda, dan ini seharusnya berhasil:
service ssh start
Dalam kasus skrip init sysv, hanya itu yang perlu Anda lakukan. Alasan hilangnya direktori adalah /var/run adalah symlink ke /run dan /run adalah tmpfs titik pemasangan. Artinya pada setiap boot /var/run akan mulai kosong. Saat Anda menggunakan service perintah /etc/init.d/ssh skrip akan digunakan untuk memulai sshd tetapi sebelum melakukan itu skrip akan membuat /var/run/sshd jika tidak ada.
Dengan systemd hal-hal bekerja sedikit berbeda. Akan ada file bernama /usr/lib/tmpfiles.d/sshd.conf dengan konten ini:
d /var/run/sshd 0755 root root
Selama boot ini akan menyebabkan /var/run/sshd direktori yang akan dibuat. Apa yang Anda butuhkan untuk memverifikasi bahwa file tersebut ada dan memiliki konten yang benar. Jika /var/run/sshd direktori masih hilang, Anda dapat memverifikasi apakah itu dibuat saat Anda menjalankan systemd-tmpfiles --create secara manual.
Solusi 2:
Jadi /run (dan /var/run disinkronkan dengannya) dibuat ulang setiap reboot. Kecuali bahwa file systemd-tmp tidak melakukan itu untuk beberapa file termasuk (/var)/run/sshd.
Rupanya, ini diperbaiki dengan pemutakhiran kernel OpenVZ. Tetapi untuk benar-benar memperbaikinya sekarang Anda mengedit /usr/lib/tmpfiles.d/sshd.conf dan hapus /var dari baris d /var/run/sshd 0755 root root untuk membaca sebagai gantinya:
d /run/sshd 0755 root root
Dan itu dia..!
Dan ketika openssh-server ditingkatkan, kami berharap mereka akan memperbaiki bug ini (atau apakah itu benar-benar bug di systemd? atau openvz??) -- jika tidak, Anda dapat mengalami masalah yang sama.
Solusi 3:
Tampaknya ini teratasi saat menjalankan kernel OpenVZ 2.6.32-042stab134.7 atau yang lebih baru. Saya merasa aneh bahwa tidak ada perbaikan yang mungkin dilakukan dalam skrip start systemd. Mungkin peretasan yang jelek seperti membuat /run/sshd/ secara otomatis setelah memulai dan kemudian memulai sshd akan berhasil.
Output dari systemd-tmpfiles --create saya :
[/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
Log perubahan OpenVZ 2.6.32-042stab134.7 mengatakan ini:
Menjalankan wadah Ubuntu dengan systemd 229-4ubuntu21.9 dapat menyebabkan layanan gagal dimulai karena systemd-tmpfiles tidak dapat memvalidasi jalur karena masalah penautan symlink. (PSBM-90038)
Solusi 4:
Untuk masalah sebanyak yang saya alami dengan systemd selama bertahun-tahun, saya harus mengakui bahwa masalah ini berasal dari sinkronisasi yang memungkinkan pengarahan.
Untuk beberapa alasan, setelah menyediakan host ini dengan skrip ansbile kami, ia meninggalkan direktori / (serta /etc, /opt dan lainnya) yang dimiliki oleh pengguna admin, dan bukan root. Setelah menjalankan chown untuk mengoreksi, /var/run/sshd sekarang dibuat saat boot lagi.
Saya sangat menghargai semua masukan tetapi tidak ada bug di sini, setidaknya dalam arti bahwa menerapkan kepemilikan yang tidak tepat ke direktori root menyebabkan perilaku sistem yang tidak terdefinisi.