Řešení 1:
Jedna chyba, kterou jste udělali, byl pokus o spuštění sshd ručně.
Pokud místo toho spustíte sshd oficiálními prostředky by to prostě mělo fungovat. service příkaz ví, jaký je správný způsob spuštění služby ve vaší distribuci, a mělo by to fungovat:
service ssh start
V případě inicializačních skriptů sysv je to vše, co musíte udělat. Důvod, proč adresář chybí, je /var/run je symbolický odkaz na /run a /run je tmpfs montážní bod. To znamená při každém spuštění /var/run začne naprázdno. Když použijete service příkaz /etc/init.d/ssh skript bude použit ke spuštění sshd ale předtím skript vytvoří /var/run/sshd pokud neexistuje.
S systemd věci fungují trochu jinak. Bude soubor nazvaný /usr/lib/tmpfiles.d/sshd.conf s tímto obsahem:
d /var/run/sshd 0755 root root
Během bootování by to mělo způsobit /var/run/sshd adresář, který má být vytvořen. Co potřebujete k ověření, že soubor existuje a má správný obsah. Pokud /var/run/sshd adresář stále chybí, můžete ověřit, zda se vytvoří při spuštění systemd-tmpfiles --create ručně.
Řešení 2:
Takže /run (a /var/run s ním spojený) se znovu vytvoří při každém restartu. Až na to, že systemd-tmpfiles to u některých souborů včetně (/var)/run/sshd nedělá.
Zřejmě je to opraveno upgradem jádra OpenVZ. Chcete-li to ale nyní skutečně opravit, upravte /usr/lib/tmpfiles.d/sshd.conf a odstraňte /var z řádku d /var/run/sshd 0755 root root číst místo toho:
d /run/sshd 0755 root root
A je to..!
A až bude openssh-server upgradován, doufáme, že tuto chybu opraví (nebo je to opravdu chyba v systemd? nebo openvz??) - jinak byste mohli narazit na stejný problém.
Řešení 3:
Zjevně se to vyřeší spuštěním jádra OpenVZ 2.6.32-042stab134.7 nebo novějšího. Připadá mi zvláštní, že ve startovacích skriptech systemd nějak není možná žádná oprava. Pravděpodobně by fungoval ošklivý hack, jako je automatické vytvoření /run/sshd/ po spuštění a následné spuštění sshd.
Výstup mého 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
Changelog OpenVZ 2.6.32-042stab134.7 říká toto:
Spuštění kontejnerů Ubuntu se systemd 229-4ubuntu21.9 by mohlo způsobit, že se služby nespustí, protože systemd-tmpfiles nemohl ověřit cestu kvůli problémům se symbolickým odkazem. (PSBM-90038)
Řešení 4:
I když jsem měl se systemd v průběhu let tolik problémů, musím přiznat, že tento problém pramení místo toho z Ansible synchronize směrnice.
Z nějakého důvodu po zřízení tohoto hostitele našimi skripty ansbile opustil adresář / (stejně jako /etc, /opt a další) vlastněný uživatelem admin, a ne rootem. Po spuštění chown opravit věci, /var/run/sshd je nyní znovu vytvořen při spouštění.
Opravdu oceňuji všechny příspěvky, ale není zde žádná chyba, alespoň v tom smyslu, že použití nevhodného vlastnictví na kořenové adresáře způsobilo nedefinované chování systému.