chrootにルートをバインドするときのENOSPC

chrootにルートをバインドするときのENOSPC

chroot環境に侵入するためにカスタムスクリプトを使用しています。 (これはセキュリティ刑務所ではありません。制御されたインストールされたパッケージとツールセット(ホスト環境とは異なります)を使用して他のタスクをコンパイルして実行できるようになります。 - ホストはUbuntu、chrootはDebianです。

この場合、スクリプトはかなり標準的なインストールセットと見なされる操作を実行します。

mount -t proc "$ROOTPATH/proc"
mount -t sysfs "$ROOTPATH/sys"
mount --bind /dev "$ROOTPATH/dev"
mount --bind /dev/pts "$ROOTPATH/dev/pts"

しかし、chrootの内部からホストファイルシステムにアクセスしてファイルを前後にコピーできるようにしたいです(前述のように、これは実際には刑務所ではありません)。

mount --rbind / "$ROOTPATH/host"
mount --make-rslave "$ROOTPATH/host"

(このコマンドは次のようになります.この回答.)

ほとんどの場合、これは期待どおりに正しく機能します。

ただし、chroot環境に何度も入っていくと(もちろん終了するとそのumountが実行されます)、rbind上記の呼び出しは最終的に失敗し、次のようになります。

mount(2) system call failed: No space left on device.

利用可能なディスク容量(および参照によるとinode)がたくさんありdf -i、もちろん実際にはスペースを使用するのではなく、既存のファイルシステムをバインドする必要があります。

もちろん、ルートファイルシステムはもちろん$ROOTPATH/hostそれ自体を含んでいるので(または実際にはこの場合は一種の - 実際には/mnt. 下にマウントされた他のファイルシステムに常駐するので、これには若干の再帰的な奇妙さが含まれます。 しかし、マウントされたファイルシステムホストを表示したいのですが、chrootにも適用されるため、再帰マウントを使用します。しかし、私が言ったように、ほとんどの場合これはうまくいきます。

私の考えでは、この質問はそれに関連していると思います。しかし、私は$ROOTPATHchroot内に含まれているファイルシステムにアクセスできるようにしたいと思います。私は無限に繰り返さないことが十分に賢いと思います(そして$ROOTPATH/host/$ROOTPATH他のマウントポイントではなく空です)。実際、これはコマンドが機能する場合です。

単一のコマンドを使用します。

mount --rbind --make-rslave / "$ROOTPATH/host"

システムがENOSPC状態であっても正常に実行されますが、再帰マウントではなく単純バインドマウントのみを実行します。

他に何をすべきか?それともエラーを「削除」して再び動作させる方法はありますか?

(システムを再起動すると再び機能しますが、毎回それをしたくありません。)

ベストアンサー1

おすすめ記事