GNU/Linux >> Linux の 問題 >  >> Linux

ブートのたびに /var/run/sshd が見つからないのはなぜですか?

解決策 1:

sshd を開始しようとしたのが 1 つの間違いでした

代わりに sshd を開始すると 公式の手段を通して、それはうまくいくはずです。 service コマンドは、ディストリビューションでサービスを開始する正しい方法が何であるかを認識しており、これは機能するはずです:

service ssh start

sysv init スクリプトの場合は、これだけで十分です。ディレクトリがない理由は /var/run /run へのシンボリックリンクです および /run tmpfs です マウントポイント。つまり、ブートごとに /var/run 空から始まります。 service を使用する場合 /etc/init.d/ssh に命令する スクリプトは sshd を開始するために使用されます ただし、それを行う前に、スクリプトは /var/run/sshd を作成します 存在しない場合。

systemd で 動作が少し異なります。 /usr/lib/tmpfiles.d/sshd.conf というファイルがあります この内容で:

d /var/run/sshd 0755 root root

起動中に、これにより /var/run/sshd が発生するはずです 作成するディレクトリ。ファイルが存在し、内容が正しいことを確認するために必要なもの。 /var/run/sshd の場合 systemd-tmpfiles --create を実行すると作成されるかどうかを確認できます。

解決策 2:

そのため、再起動するたびに /run (およびそれにシンボリックリンクされた /var/run ) が再作成されます。 systemd-tmpfiles が (/var)/run/sshd を含む一部のファイルに対してそれを行っていないことを除いて。

どうやら、これは OpenVZ カーネルのアップグレードによって修正されています。しかし、実際に修正するには /usr/lib/tmpfiles.d/sshd.conf を編集します /var を削除します d /var/run/sshd 0755 root root 行から 代わりに読む: d /run/sshd 0755 root root

それだけです..!

そして、openssh-server がアップグレードされたときに、このバグが修正されることを願っています (または、これは本当に systemd または openvz のバグですか??) -- そうしないと、同じ問題が発生する可能性があります。

解決策 3:

どうやらこれは、OpenVZ カーネル 2.6.32-042stab134.7 以降を実行すると解決されるようです。 systemd の起動スクリプトで何らかの修正ができないのは奇妙だと思います。おそらく、起動後に /run/sshd/ を自動的に作成してから sshd を起動するような醜いハックが機能するでしょう。

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

OpenVZ 2.6.32-042stab134.7 の変更ログには次のように書かれています:

<ブロック引用>

systemd 229-4ubuntu21.9 で Ubuntu コンテナーを実行すると、シンボリック リンクの問題により systemd-tmpfiles がパスを検証できなかったため、サービスの開始に失敗する可能性がありました。 (PSBM-90038)

解決策 4:

何年にもわたって systemd で抱えてきた問題と同じくらい、この問題が Ansible synchronize に起因していることを認めなければなりません。 指令。

何らかの理由で、このホストを ansbile スクリプトでプロビジョニングした後、root ではなく、管理者ユーザーが所有する / ディレクトリ (および /etc、/opt など) を残しました。 chown を実行した後 物事を修正するには、/var/run/sshd 再起動時に作成されるようになりました。

すべての意見に本当に感謝していますが、少なくともルート ディレクトリに不適切な所有権を適用すると未定義のシステム動作が引き起こされたという意味では、バグはありません。


Linux
  1. /var/log/messages、/var/log/syslog、および/var/log/kern.logの違いは?

  2. 修正::SSHエラー:sshdの開始:特権分離ディレクトリがありません:/ var / empty / sshd

  3. /var/www/... の Django static_root - collectstatic へのアクセス許可がありません

  1. スリープなしで数回反復した後、この遅延ループがより速く実行されるのはなぜですか?

  2. NGINX:unix:/var/run/php7.0-fpm.sock への connect() が失敗しました (2:そのようなファイルまたはディレクトリはありません)

  3. /dev/shm/ と /tmp/ はいつ使用する必要がありますか?

  1. ブート パーティションのサイズ変更

  2. /home、/usr、/var などのディレクトリがすべて同じ inode 番号 (2) を持っているのはなぜですか?

  3. /dev/tcp を使用するために < または > が必要な理由