udevとの戦い

Question 1

systemd-udev 本物ルールから直接ファイルシステムをマウントする必要はありません。このサイトでこれに関する多くの質問を見つけることができます:-).

最新バージョンのsystemdでは、udevサービスファイルにSystemCallFilter=@system-service @module @raw-io。ファイルシステムのマウントに必要なシステムコールは許可されません。

（そして、一度mountFUSEファイルシステムに対して直接ntfs-3gFUSEサーバープロセスを開始する場合は、それを専用のシステムデバイス（例：unit）に配置するのが最善です.mount。現在のデバイス内でFUSEプロセスを維持する場合、FUSEプロセスのライフサイクルは実行中のデバイスのライフサイクルと組み合わせられます。

RUN+=ルールのコマンドに関連する将来（または現在の）問題を回避するには、代わりに次のようにENV{SYSTEMD_WANTS}=my-automounter@%k.service使用できます。

# /etc/systemd/system/[email protected]
[Service]
Type=oneshot
ExecStart=/usr/local/libexec/my-automounter %I

#!/bin/sh
# /usr/local/libexec/my-automounter

DEV=/dev/"$1"

# You can make this script as complicated as you want.
# You can read udev properties if you want, using 
# eval "$(udevadm info --query=property --export "$DEV")"
...

デバイスコールを手動でテストするには、を使用できますsystemctl start my-automounter@sdc1。

systemdがスクリプトの実行中にエラーが発生した場合、またはsystemctl status my-automounter@*を使用してエラーメッセージを表示できますjournalctl -b -u my-automounter@*。

また、udev特定のエラーレポートを処理する必要はありません。プログラムが突然停止した場合に備えて、どちらも便利なエラー報告機能がshあると思います。たとえば、:-)でブロックされたシステムコールを呼び出そうとしたため、systemdプログラムがシグナルによって終了したことを報告する必要があります。SIGSYSSystemCallFilter=

Answer

systemd-udev 本物ルールから直接ファイルシステムをマウントする必要はありません。このサイトでこれに関する多くの質問を見つけることができます:-).

最新バージョンのsystemdでは、udevサービスファイルにSystemCallFilter=@system-service @module @raw-io。ファイルシステムのマウントに必要なシステムコールは許可されません。