公式Dockerリポジトリを使用してchrootを有効にすると、高いSFTP CPU使用率

公式Dockerリポジトリを使用してchrootを有効にすると、高いSFTP CPU使用率

Docker、Fedora 37、および5億以上のフルSFTPイメージに関連するかなりのニッチの問題がありますatmoz/sftp

Fedoraではなく公式リポジトリからDockerをインストールしましたが、SFTPサーバーにログインしようとすると、コンテナは100%のCPUコアを使用しました。 1〜2分後、ついにログインしてsftp>メッセージを受け取りました。

SFTPサーバーの起動

docker container run \
--interactive \
--tty \
--rm \
--name sftp-cpu-problem-debug \
--publish 2222:22 \
--env SFTP_USERS=cpuproblem:123:::IN \
atmoz/sftp:alpine

# You might have to kill it from a separate session using docker kill sftp-cpu-problem-debug

ログインしよう(別途の端末セッションで)

sftp -P 2222 -oLogLevel=DEBUG3 cpuproblem@localhost
# Password is 123

また、DEBUG3ロギングを使用してSSHデーモンを起動しようとしましたが、ログエントリはCPUに問題がないものと同じです。

ChrootDirectory %hコンテナのファイルからその行を削除すると、/etc/ssh/sshd_config公式のDockerパッケージを使用しても問題なくログインします。もちろん、これはchrootを無効にします。

次の試みでは、それぞれCPUの問題なくログインできるSFTPコンテナが機能しました。

  • Dockerの代わりにPodmanを使用して同じイメージを使用してコンテナを起動し、デフォルトでchrootを有効にしたSFTP設定を使用します。
  • moby-engineDockerリポジトリの公式Dockerパッケージの代わりにFedoraリポジトリのパッケージを使用してください。
  • DebianのWSL2で公式Dockerリポジトリパッケージを使用してください。

これは一種のFedora設定の問題のようです。同じバージョンがDebianで動作し、Fedoraパッケージ(以前のマイナーバージョン)も動作するためです。

  • Fedoramoby-engineパッケージは、公式Dockerパッケージが構成しないものを構成しますか?
    • 関連性はないかもしれませんが、Spring Securityにエントロピーが不足して使用されていないため、Spring Javaアプリケーションがゆっくり起動する状況が考えられます/dev/urandom
    • これは非常に奇妙な極端な状況です。
      • SFTPプロンプトを表示する前にSSHデーモンが計算を試みるものは何ですか?
      • chrootを無効にすると、この問題が解決するのはなぜですか?
      • Debianでは、なぜこれが問題にならないのですか?
  • SELinuxを許可的に実行するように設定し、SELinuxで実行も試みましたが、--privilegedまだCPUの問題があります。
  • コンテナからOpenSSHを手動で更新しようとしましたが、それも役に立ちませんでした。

ベストアンサー1

今日この問題に遭遇し、いくつかのstrace検索の最後にAlexandru Scvorşovの次のブログ記事を見つけました。

56. ログイン後 12 分後に SFTP ブレークをデバッグする

必ず読んでくださいが、簡単に言うと、OpenSSHはBSD固有のシステムコールを使用して、指定された整数より大きいすべてのファイル記述子を閉じます。このシステムコールはLinuxでは利用できないため、フォールバック実装はclose()システム制限に達するまで各候補ファイル記述子を呼び出します。

この資料では、この問題を解決するのに役立つ詳細について説明します。

おすすめ記事