mount(8) この systemd MountFlags を無視できますか?

mount(8) この systemd MountFlags を無視できますか?

私はDebian stretch/4.14.75長年にわたって独自の自動インストーラ()を開発して使用してきました。udev-hook + shell-script

automounter-script.

しかし、

# sed -i "/^MountFlags/s/=.*$/=shared/" \
    /lib/systemd/system/systemd-udevd.service

再び良いことを確認するために、名前空間を名前空間に再度伝播することが可能かどうか、 mount(8)または他の作業が可能かどうか疑問に思います。root

MountFlags=slave私の考えでは、彼らが債務不履行をしたのに妥当な理由があると思いますか、それとも?

答え1

いいえ。分離されたマウント名前空間で実行されると、実際にマウントをルート名前空間に伝播することはできません。

マウントネームスペースサンドボックスを無効にすることに加えて、次のものを使用できます。systemd-mountこの問題を解決してください。

サンドボックスの基本原理

systemdは、ファイルシステムを直接マウントするのではなく、udevルールからudevルールからユニット(つまりマウントユニット)を開始するように指示することを好みます。これが、udevdがMountFlags=slaveホストマウントを汚染するためにファイルシステムを一時的にマウントしようとするルールエラーやルールを防ぐために、別々のマウントネームスペース()で実行される理由です。

しかし、もちろん、あなたの場合は、自動化されたインストーラスクリプトを介して実行したいことです。

システムマウント

次の呼び出しを置き換えて、udevdの別々のマウントネームスペース内で機能するように自動マウントスクリプトを調整できますmountsystemd-mountはと同じパラメータを持つツールmountです。設置単位そして自動設置装置この目的のために、両方のデバイスは、再/run/systemd/system起動後も持続しない一時ディレクトリの下に作成されます。 )

上書きしてマウントサンドボックスを無効にします。

udevdマウントネームスペースのサンドボックスを無効にするには、/libsystemdパッケージに付属の構成ファイルを変更する代わりに、オーバーライド構成ファイルを使用します(次にaptがパッケージをアップグレードすると壊れる可能性があります)。 )

次のコマンドを使用して、エディタでオーバーレイファイルを開くことができます。

$ sudo systemctl edit systemd-udevd

MountFlags次の2行を使用してデフォルト値(「共有」)にリセットできます。

[Service]
MountFlags=

変数を空の文字列に設定すると、通常はsystemdのデフォルト値にリセットされます。

最新バージョンのsystemdでは、これが設定に使用されますPrivateMounts=犯罪udevdサービスファイルを変換して使用してください。

これはオーバーレイの問題の1つを強調します。つまり、標準のsystemd構成から外れているため、最新のsystemdにアップグレードしても機能し続けるには追加または代替構成が必要なため、オーバーレイを調整する必要がある場合があります。

また、まずudevdを独自のマウントネームスペースにサンドボックス化するという利点も失われます。

したがって、使用されているソリューションがsystemd-mountお客様に適している場合は、上書きするよりも適切なソリューションをお勧めします。

答え2

システムユニットは次の場所に保存されます。

   /etc/systemd/system/* - local configuration
   /run/systemd/system/* - runtime units
   /usr/lib/systemd/system/* - units of installed packages

何かを変更したい場合は、/usr/lib/systemd/system/ディレクトリ内のファイルを変更せずに、ディレクトリに同じ名前の新しいユニットファイルを作成する必要があります/etc/systemd/system/

からman systemd.unit

ユニットファイルのベンダー設定を上書きする方法は2つあります。/usr/lib/systemd/システム到着/etc/systemd/システム選択した設定を変更します。または、次のディレクトリを作成できます。単位.d/以内に/etc/systemd/システム挿入したファイルを配置します。name.conf人々が興味を持っている特定の設定だけがそこで変更されます。これらの挿入ファイルが複数ある場合は、そのファイルを読み込みます。

最初のアプローチの利点は、ユニット全体を簡単に扱うことができ、サプライヤーユニットを解析する必要がなくなることです。欠点は、ベンダーのユニットファイルの改善がアップデートに自動的に統合されないことです。

2番目のアプローチは、必要な特定の設定のみを上書きし、デバイスのベンダーアップデートが自動的に適用されるという利点があります。欠点は、ベンダーの一部の将来の更新がローカルの変更と互換性がない可能性があることです。

systemd上記のようにボリュームをマウントするための独自のメカニズムがあります。ここ:

systemd は、/etc/fstab で指定されたパーティションとファイルシステムのマウントを担当します。 systemd-fstab-generator(8) /etc/fstab のすべてのエントリを systemd 単位に変換します。これは、起動時にシステム管理者構成が再ロードされるたびに実行されます。

systemdで独自のサイレントインストーラを使用すると、不要な問題が発生すると思います。

関連情報