edit-a-live-config-safely

Edit a live config safely

Editing a configuration file that a process is already reading is not the same as editing a source file. The file is an interface with something that is running, and three of the four ways it goes wrong leave the file looking perfectly correct afterwards.

The four rules

1. Substitute by unique anchor. Never rewrite the file

Find an exact string, replace that string. Do not regenerate the file from a template, do not "clean it up while you are there", do not reorder it.

⚠️ Check that the anchor appears exactly once, before replacing. Count it:

rg -c --fixed-strings 'the exact text you are anchoring on' path/to/config

If the count is not 1, the anchor is wrong. Extend it — take more surrounding lines until it is unique.

🔴 This is how latent bombs get in. A repeated anchor puts the change in the wrong block, and the file is still syntactically valid. Nothing complains. The process reloads happily. The change simply applies to the wrong service, the wrong host, the wrong environment — and it is found weeks later by whoever is debugging something that seems unrelated.

A file that fails to parse is a good outcome. It tells you immediately. The dangerous edit is the one that parses.

2. Keep the inode

Write in place. Do not use anything that writes a temporary file and renames it over the original.

Why: when a single file is mounted into a running process — a common way to inject one config file without mounting a whole directory — the mount resolves to the inode. Replace the file and the mount still points at the old inode. The file on disk shows your change. The process is reading the previous contents. Every tool you use to check agrees with you, and the process disagrees with all of them.

The same trap catches anything holding an open file descriptor across the edit.

Safe: an in-place edit that opens and writes the existing file. Unsafe: any "atomic write" helper, any mv of a new file over the old one, any editor configured to write-then-rename.