The four steps inside `sed -i` are the whole failure. It opens the target for reading, opens a temp file in the same directory, streams the transformed bytes into it, and calls `rename(2)` to move that temp file over the target name [7]. All four succeed. The path on the host now resolves to a fresh inode carrying the new content, which is exactly why `md5sum` on the host looked correct [4]. The mount was established when the container started, against the inode the name pointed at then, and single-file bind mounts are bound to inodes rather than to directory entries [8]. The rename moved the name, but the mount stayed with the inode.
Both `stat` outputs report the same device, fc01h/64513d [5][6]. One filesystem here holds two live inodes, and no copying is involved [3]. The container's inode reports `Links: 0`, which means no directory entry anywhere on that filesystem points at it, and the only thing keeping it from being freed is the descriptor the container still holds [9]. That field means no directory entry points at this file anymore except through the descriptor your process holds.
The sizes deserve a minute of arithmetic. The host file is 2847 bytes and the file the container reads is 2791 [5][6], a gap of 56 bytes [1]. The substitution shown in the post swaps `15s` for `30s`, three bytes for three bytes, so it moves the size by zero [2]. Whatever produced 56 bytes of divergence is therefore not in the command list the post publishes, which points at an earlier atomic write having already detached the mount well before anyone started debugging this reload.
The escape the author used first is `cat > file`, which opens the existing inode with `O_TRUNC` and writes into it, leaving the inode number unchanged so the container sees the new bytes at once [10]. That transfers only if two things hold: the writer can open the existing inode, and you control every tool that ever writes that path, because anything ending in a rename puts you back where you started [11]. It also gives up the property `rename(2)` was invented to provide. `O_TRUNC` empties the file before the new content lands, so a SIGHUP arriving in that window reads a short config [4]. The second escape, `docker compose up -d --force-recreate prometheus`, keeps atomic writes and pays a container restart instead, and the author reaches for it when the config change is paired with an image bump, an env-var change, or a sibling edit [12].
In my context I take the recreate for anything a process rereads on signal. A few seconds of scrape gap is bounded and visible in the graphs. A ghost inode is neither, and it cost this team an hour before they thought to run `stat` [13]. The cheap instrument here is comparing inode numbers across the container boundary rather than checking content on the host [11]; the expensive habit is trusting that a 200 from a reload endpoint says anything about which bytes were read.
