シンボリックリンクパスへのopenat呼び出しでEROFSエラーが発生するのはなぜですか？

断続的に（通常はサーバーごとに1〜2回だけ）表示され消える問題をデバッグしようとしています。フラグを使用してロックされたopenat()ファイルを開こうとするアプリケーションがありますO_WRONLY|O_CREAT。環境設定のため、このロックファイルは読み取り専用ネットワーク共有に存在する必要があるディレクトリにあります。 （技術的にはこれはAWS EFS共有ですが、NFS共有のように見えます。）

マウントポイントは読み取り専用なので、アプリケーションがロックファイルがあると予想するパスにシンボリックリンクを配置します。シンボリックリンクターゲットは存在しないパス/tmp（書き込み可能）です。

# ls -l /mnt/share/files/.LOCK
lrwxrwxrwx 1 nfsnobody nfsnobody 16 Jan  1  1970 /mnt/share/files/.LOCK -> /tmp/application.LOCK
# ls -l /tmp/application.LOCK 
ls: cannot access /tmp/application.LOCK: No such file or directory

通常、これはうまくいきます。アプリケーションが開きますターゲットリンク、ファイルの作成（下/tmp）、すべてをお勧めします。ただし、サーバーを構成して初めてア​​プリケーションを起動すると、アプリケーションがこのファイルに書き込めないことがあります。EROFS（読み取り専用ファイルシステム）エラーのため、書き込みに失敗しました。

私はstrace -s 1024 -y -e trace=%file -fエラーとそれに応じて成功を実行してキャッチしました。両者の間に顕著な違いはありません。

...
[pid 17654] openat(AT_FDCWD, "/mnt/share/files/.LOCK", O_WRONLY|O_CREAT, 0666) = -1 EROFS (Read-only file system)
...
[pid 17654] openat(AT_FDCWD, "/mnt/share/files/.LOCK", O_WRONLY|O_CREAT, 0666) = 112</tmp/application.LOCK>
...

このテストの前には/tmp/application.LOCK存在せず、それ以降は/tmp/application.LOCKテキストを含む一般的なファイルがあります。test\n

echoを実行すると、straceほぼ同じシステムコールが表示され、試行するたびに成功します。

# strace -s 1024 -y -e trace=%file -f bash -c "echo test > /mnt/share/files/.LOCK`
execve("/usr/bin/bash", ["bash", "-c", "echo test > /mnt/share/files/.LOCK"], 0x7ffc3a86df10 /* 22 vars */) = 0
...
access("/usr/bin/bash", R_OK)           = 0
openat(AT_FDCWD, "/mnt/share/files/.LOCK", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3</tmp/application.LOCK >

関連性があると思われる1つは、アプリがで実行されるシステムサービスであることですProtectSystem=full。PrivateTmp=yesしかし、PrivateDevices=yesこれは変更されていないので、アクセスが時々機能して失敗する理由が何であるかはわかりません。 （はい。それだけでなく、systemdによって生成されたプライベート一時ディレクトリも確認してみましたが、呼び出しが成功すると期待/tmpどおりにファイルが生成されます。）/tmp/systemd-private-blah/tmp/

EROFS書き込みシンボリックリンクを使用するときに時々/断続的に発生する（読み取り専用ファイルシステム）エラーは何ですか？openat()