私のホームネットワークには2つのサーバーがあります。
- Linuxサーバー。 （現在はsystemdを使用してDebianを実行していますが、これにはDebianに関連するものはないと思います。）
- NASサーバー。 （ネットワーク接続ストレージ。）
停電後、両方のサーバーの電源が同時にオンになります。しかし、LinuxサーバーはNASサーバーよりも速く起動します。。 Linuxサーバーはネットワークにアクセスでき、CIFS共有をマウントしようとしますが、NASサーバーがまだ準備されていないため失敗します。
NASサーバーの起動に時間がかかる場合でも、Linuxサーバーが自動的にCIFSマウントをマウントできるようにするにはどうすればよいですか? （いくら？仮定しましょうカップル分。 )
現在の構成
Linuxサーバーには次の行/etc/fstab（匿名）があります。
//192.168.XX.XX/Foobar /mnt/Foobar cifs credentials=/etc/fstab-cifs-credentials,rw,uid=1000,gid=1000,nobrl 0 0
また、実行中であり、systemdネットワークsudo systemctl show mnt-Foobar.mount依存関係が自動的に構成されていることも示しています。
…
Wants=network-online.target
After=system.slice network.target systemd-journald.socket network-online.target remote-fs-pre.target -.mount
…
journalctlまたは、次のように表示されるエラーメッセージsudo systemctl status mnt-Foobar.mount：
mount[544]: mount error(113): could not connect to 192.168.XX.XXUnable to find suitable address.
手動でトリガーしたり、NAS サーバーを起動した後に Linux サーバーを再起動すると、マウントが正常に動作します。
何が必要ですか
完全に放棄する前に、各試行間に少し遅れてインストールを数回やり直すことができるソリューションが必要です。
または、継続的にインストールを再試行するソリューションです。
あるいは、サーバーがまだ準備されていなくても、サーバーが最終的に準備されると信じてマウントが成功したと見なすソリューションです。 （サーバーが準備されていない場合は、数分間すべてのアクセスがブロックされます。）
または、ネットワークファイルシステムをマウントする前に固定のランダム遅延を導入するソリューションです。
ボーナス：サービスの依存関係
NASに保存されているファイルを使用するDockerサービスがいくつかあります。このタイプのDockerサービスには、/mnt/FoobarDockerコンテナからボリュームへのマッピングがあります。したがって、すべてのCIFSマウントが準備されたら、dockerサービスを開始する必要があります。
これらのサービス依存関係を設定することは、別の質問のトピックです。ただし、この問題に対する解決策はDockerの起動依存関係とうまく機能するはずです。
解決策
現在の解決策は、LinuxサーバーにSSHを手動で接続してから再起動するか、共有を手動でマウントすることです。 （そして手動でDockerサービスを再起動してください。）確かに理想的ではなく、あまりにも多くのサーバー管理が必要です。
答え1
次のようにfstabに "x-systemd.automount"を追加します。
//192.168.XX.XX/Foobar /mnt/Foobar cifs credentials=/etc/fstab-cifs-credentials,rw,uid=1000,gid=1000,nobrl,x-systemd.automount 0 0
Systemdはすべてを処理します。
答え2
完全にテストされていません：
$ cat /usr/local/libexec/cifs-mounter.sh
#! /bin/bash
SRV=192.168.0.111 # FQDN or IP address
while ! nc -z $SRV 445; do
sleep 10
done
mount -t cifs //$SRV/share /mnt/point
$ cat /etc/systemd/system/multi-user.target.wants/cifs-mounter.service
[Unit]
Description=CIFS mounter
After=network.target
[Service]
ExecStart=/usr/local/libexec/cifs-mounter.sh
KillMode=process
Restart=on-failure
RestartSec=30s
[Install]
WantedBy=multi-user.target
答え3
簡単に言うと：x-systemd.automountインストールオプションに追加するには:Zardoz89からの返信。
今、あまりにも早く起動してドッカーコンテナを（再）起動できないという他の問題があります。しかし、それは別の質問です。
公式文書は次の場所にあります。man systemd.mount。この文書はSUSEサポートで提供されています。とても役に立ちます。
_netdev
オプションがありますが、次_netdevの理由で必要ありません。
通常、ファイルシステムタイプは、マウントが「ネットワークマウント」かどうか、つまりネットワークが利用可能になった後にのみ起動する必要があるかどうかを判断するために使用されます。このオプションを使用すると、この検出は無視され、インストールにネットワークが必要であることを指定します。
実際にインストールされた2つのデバイスsystemctl show mnt-Foobar.mount（このオプションを持つデバイスとはないデバイス）の出力を比較しましたが、非常に似ていました。具体的には、、、とは同じです（ただしAfter、順序は異なりますが、順序は重要ではありません）。RequiredByRequiresMountsForRequiresWants
x-systemd.automount
次のようなZardoz89からの返信x-systemd.automount、マウントポイントに追加しようとしました。
systemctl list-automounts再起動後、またはを見ると検出されたことを確認できますsystemctl list-units '*mount*'。
これらのディレクトリのエントリにアクセスしようとすると、エラーが返されます。
$ tree
.
└── Foobar [error opening dir]
$ ls -R
.:
Foobar
ls: cannot open directory './Foobar': No such device
幸いなことに、サーバーで共有フォルダが利用可能になると、ディレクトリは再び機能し始めます。
ドッカーの失敗
これらの共有フォルダー内のボリュームを使用するDockerコンテナーは、これらのボリュームが使用可能になった後でもまだ起動せず、ダウン状態のままです。たぶん私はもう少しできます。健康診断この問題を解決してください。それとも試してみますが、とにかくそれは別の質問です。
サービスの依存関係
各サービスに体系化された単位がある場合は、次のことができます。/etc/fstabファイルから直接マウントポイントの依存関係を宣言します。、次のオプションの1つ以上を追加してください。
x-systemd.after=x-systemd.before=x-systemd.required-by=x-systemd.wanted-by=
各項目の意味について説明します。男性システムユニット。
x-systemd.device-timeoutとx-systemd.mount-timeout（私には機能しません）
これを使用したくない場合は、x-systemd.automount次のようにデバイスのマウントのタイムアウトを宣言して増やすことができます。
x-systemd.device-timeout=x-systemd.mount-timeout=
s時間は、またはmin（またはh何らかのms理由で）指定できます。
ただし、使用しようとすると機能しません。 15分のタイムアウトがあるにもかかわらず、これらのマウントポイントは再起動後も失敗します。したがって、これらはうまくいかないか、私はそれらについて十分に知らないので、私には効果がありません。
これは、サービスが適切な瞬間にのみ開始されるようにシステムの依存関係と組み合わせることができます。