私は特定のUSBスティックが挿入される時期を識別するためにudevルールを使用しています。接続すると、一部のデバイスをインストールするためにbashスクリプトが起動します。説明したように、systemd-udevサービスをいくつか変更した後、うまく機能しました。ここ。
しかし、インストールの1つが失敗しました。ヒューズマージマウント。コマンド自体は成功したようですが、インストールlsフォルダで操作を実行すると奇妙な出力が表示され、フォルダにアクセスできません。
d????????? ? ? ? ? ? mountpoint
しかし、端末でmountコマンドを手動で実行すると、すべてが正常です。
起動中にスティックを挿入するかシステム起動後に挿入するかは関係ありません。mountfusion-mergerfsデバイスマウントは、udevスクリプトから呼び出すときには効果がありません。
どんな考えがありますか？
ベストアンサー1
[udev ルールでの RUN の使用] は、タイムアウト後も実行を続けると終了するため、寿命の短いスクリプトでのみ機能します。
つまり、ファイルシステムを実装するFUSEバックグラウンドプロセスが終了します。
代替案を考えました。コマンドがある場合は、systemd-mountコマンドの代わりにそれを試すことができますmount。一時.mountセル（.serviceセルではない）を作成し、mountそのセル内でプログラムを実行します。
私が引用したソースは、長期実行プロセスのより一般的なソリューションを提供しようとします。
https://yakking.branchable.com/posts/systemd-2-udevd/
より長く実行されるサービスが必要な場合は、次のように単位を定義してシステム単位と統合する必要があります。
cat >/etc/systemd/system/[email protected] <<'EOF' [Unit] Description=My Service [Service] Type=simple ExecStart=/path/to/your/script %I EOF
ENV{SYSTEMD_WANTS}="my-service@%k.service"udevルールに追加されました。これにより、/path/to/your/script が実行され、表示されたばかりのデバイスのパスが渡されます。
残念ながら、上記の説明はあなたの場合には適用されません。
問題は、スクリプト自体が返されるまでに時間がかかることではありません。問題は、FUSEファイルシステムを実装するプロセスである「バックグラウンドプロセス」を起動した後にスクリプトが返されることです。スクリプトが完了したら、systemdスクリプトによって開始された残りのプロセスをクリーンアップして終了する必要があると見なします。
この状況は、以前のsysvinitスクリプトと非常によく似ています。したがって、我々はそれらと同じソリューションを使用することができます。
mountFUSEファイルシステムにsystemdサービスを書き込むときやType=simple使用しないでくださいType=oneshot。代わりに使用してくださいType=forking。