systemd を使用してユーザーバスにリモートファイルシステムをマウントする

systemd を使用してユーザーバスにリモートファイルシステムをマウントする

リモート マシンのディレクトリを にマウントしたいと思います/home/stew/shared。 をリモート マシンにインストールしsshfsて使用した後ssh-copy-id、次の操作を実行できます。

stew@stewbian:~$ sshfs [email protected]:/path/to/remote-dir ~/shared

そしてアンマウントする

stew@stewbian:~$ umount ~/shared

または

stew@stewbian:~$ fusermount -u ~/shared

stewうまく動作しますが、ログイン時にこれを自動的にマウントし、stewログアウト時にアンマウントしたいと思います。 1 つの有効なオプションは.service、ユーザー バスで systemd を使用することです。

# ~/.config/systemd/user/shared.service
[Unit]
Description=Mount ~/shared

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=sshfs %[email protected]:/path/to/remote-dir %h/shared
ExecStop=umount %h/shared

[Install]
WantedBy=default.target

systemctl --user {start,stop} shared.service.mountも素晴らしいです! しかし、ユニットはもっと堅牢になるのだろうかと思います。


次のようなマウントユニットを使用してみました:

# ~/.config/systemd/user/home-stew-shared.mount 
[Unit]
Description=~/shared

[Mount]
What=%[email protected]:/path/to/remote-dir
Where=%h/shared
Type=fuse.sshfs

[Install]
WantedBy=default.target

このマウント ユニットを起動すると正常に動作しますが、停止すると次の問題が発生します。

$ systemctl --user status home-stew-shared.mount
● home-stew-shared.mount - ~/shared
     Loaded: loaded (/home/stew/.config/systemd/user/home-stew-shared.mount; static)
     Active: active (mounted) (Result: exit-code) since Mon 2021-05-24 16:49:40 CEST; 6min ago
     ...
May 24 16:49:40 stewbian systemd[1046]: Unmounting ~/shared...
May 24 16:49:40 stewbian umount[22256]: umount: /home/stew/shared: must be superuser to unmount.
May 24 16:49:40 stewbian systemd[1046]: home-stew-shared.mount: Mount process exited, code=exited, status=32/n/a
May 24 16:49:40 stewbian systemd[1046]: Failed unmounting ~/shared.

$ umount ~/sharedディレクトリをアンマウントしてユニットを失敗させることができます。


質問:

  1. *.mountユニットよりもユニットを優先する理由はありますか*.service?
  2. 本当に を使用する必要がある場合*.mount、これをユーザー バスで動作させるためのコツはありますか。それとも、システム バスに移動して、遅延マウントを実行して UID と GID を手動で設定する方法を理解する必要がありますか。

を使用することの利点の 1 つは*.service、このサービスを に追加できるskelため、各ユーザーが自分のプライベート共有ディレクトリを自動マウントし、家中のすべてのマシン間で効果的に同期できることです。*.mount正しいホームにアクセスするには、ファイル名にユーザー名が必要です。

答え1

Ubuntu 21.04 の systemd 246.6 でも同じ問題が発生します。マウント ユニットをアンマウントしようとすると、systemd は最初に でアンマウント ヘルパーを見つけようとします/sbin/umount.<type>(つまり、sshfs の場合は/sbin/umount.fuse.sshfs)。これが失敗すると が呼び出されumount2(<where>)、ユーザーの systemd によって実行されると失敗します。

なぜこれが @fra-san で機能するのかはわかりませんが、アンマウント ヘルパーがあるのではないかと思います。

これらの質問に関して:

  1. SysV スタイルの init スクリプトで何でもできるのと同じように、サービス ユニットでも何でもできますが、systemd の考え方は、一般的なシステム管理タスクを理解し、物事を過度に複雑にすることなく (メンテナンスが難しくなるように)、必要なことを実現するための最小限の記述構文を提供することです。マウント ユニットを使用してファイル システムをマウントできる場合は、基本的にスクリプトを作成するよりも望ましいです。もちろん、インフラストラクチャは必要なことをサポートできる必要があります。Ubuntu 21.04 の時点で、ユーザー マウント ユニットの現在の状態は数年前よりもはるかに改善されていますが、FUSE ファイル システムではまだ 100% ではありません。
  2. ユーザマウントユニットを停止(アンマウント)するために、私は次のようfuse.sshfsにumountヘルパーを作成しました。/sbin/umount.fuse.sshfs
#!/bin/sh
/bin/fusermount -u "$1"

その後、マウント ユニットを停止すると、うまく機能します。systemd は umount ヘルパーを呼び出して、ファイル システムを正しくアンマウントします ( umountumount ヘルパーから呼び出さないでくださいumount。ヘルパーも呼び出され、すべての pid を消費する無限ループに陥る可能性があるためです)。これはおそらく優れた解決策ではなく、systemd はumountユーザーとして呼び出したときに実行されるものを実行する必要があります (実際に何をするのかはわかりません) が、私の場合はうまく機能します。

関連情報