This can cause processes with open file descriptors to continue reading the old inode. Of particular interest are Docker mounts.
I have been trying to leverage docker-gen to render config files, and I then share those config files to other contains, ideally mounting just the rendered config files as them directly into the receiving containers filesystem as :ro. (Trying to be secure 🤷♂️)
But due to the above behavior, the receiving container never sees the new rendered config -- it continues reading the old inode and therefore old data.
This isn't necessarily a bug with docker-gen -- I fixed it for now by not mounting the file directly, but rather mounting the file's directory which alleviates the issue -- but truncating the existing inode and writing directly would have helped me out recently. Thanks for considering this issue.
It appears that
docker-gen
creates a new temporary file that is then moved to[dest]
, based at least on differing inodes.Consider the following REPL:
(The inode changes from
32639413
to32639416
.)This can cause processes with open file descriptors to continue reading the old inode. Of particular interest are Docker mounts.
I have been trying to leverage
docker-gen
to render config files, and I then share those config files to other contains, ideally mounting just the rendered config files as them directly into the receiving containers filesystem as:ro
. (Trying to be secure 🤷♂️)But due to the above behavior, the receiving container never sees the new rendered config -- it continues reading the old inode and therefore old data.
This isn't necessarily a bug with
docker-gen
-- I fixed it for now by not mounting the file directly, but rather mounting the file's directory which alleviates the issue -- but truncating the existing inode and writing directly would have helped me out recently. Thanks for considering this issue.