skip to content

Why does changing an inherited environment value require a new process, while a mounted config file can change underneath one?

level: juniorimportance: should knowfreq 58%

answer

  1. ask where the bytes live
  2. copied in at creation, not linked
  3. no channel into a running process
  4. the file's source stays writable
  5. new value means new process

basics

~20 s

An inherited name-value set is copied into the process when it is created, and nothing outside the process can edit that copy, so only a new process sees a new value. A mounted file's bytes live outside the process and can be replaced under it.

solid answer

~50 s

The two shapes differ in **where the bytes live**. An inherited set is assembled by whatever creates the process and copied into it at that moment. From then on it is the process's own memory: the platform has no channel into it, so editing the declared value changes what the *next* process will be handed and nothing about the one already running. A mounted file is the opposite — the bytes sit in the container's filesystem, outside the process, so the platform can replace them while the process runs. That is why a changed variable is a start-up-time decision and a changed file is not. The honest exception is that a process can rewrite its *own* copy of the set, which affects the children it starts afterwards but nothing about how the value was delivered.

go deeper

for a junior

Remember the one-liner: an inherited value is copied into the process when it starts, so changing the declaration only affects the next process. A file sits in the filesystem and can be replaced while the process runs.

for a middle

Explain it by location rather than by rule. Say where the bytes live in each shape, and why there is no mechanism for editing a running process's environment block from outside. Mention that a process can rewrite its own copy.

for a senior

Separate the three claims behind 'I changed it and nothing happened': the declaration changed, a new process was created, and the process actually re-read the value. Show which one the delivery shape decides and which two it does not.

for a principal

Weigh what the inherited shape buys — a configuration that cannot shift under a running process mid-flight — against the process churn every change costs, and set the convention for which class of value is allowed to be changeable at all.

## Where the value the process is using actually lives The question sounds like it is about timing, but it is about **location**. Ask, for any delivered value: where are the bytes the running process is reading? For an inherited name-value set, the answer is *inside the process*. When a process is created, whatever created it assembles a block of `NAME=value` pairs and copies that block into the new process's own memory. From that instant the block belongs to the process. The declared value in the workload spec and the copy in the process are two different things that happened to agree once, at creation. For a mounted file, the answer is *outside the process*. The bytes sit in the container's filesystem. The process reads them when it chooses to, into a variable of its own — and that parsed copy is then just as stale as an inherited variable would be. What is different is that the *source* is still there and still writable by the platform. ## Why nothing outside can edit the inherited copy There is no mechanism by which one process reaches into another and rewrites its environment block. A platform can: - change what it will hand to the **next** process it creates, and - create a new process. That is the whole list. So "apply the new value" and "create a new process with the new value" are the same action, and a value change of this shape is inseparable from a restart or a replacement. The one honest exception cuts the other way: a process **can** rewrite its own copy from inside. That changes what its future children inherit, and it changes what an inspection of the live process shows — it does not give the platform a way in, and it is not a delivery mechanism. It is worth knowing precisely because it explains why the copy and the declared value can legitimately disagree. ## What "a new process" costs The cost is not the same everywhere, and this is where platforms genuinely differ: some restart the same container in place, others replace the instance entirely and schedule a fresh one. Either way the sequence is the same shape: 1. The declared value set is updated where the platform reads it from. 2. The platform decides that the running instance no longer matches what is declared. 3. The existing process is asked to stop, finishes what it is doing, and exits. 4. A new process is created and handed a freshly assembled set. Between steps 3 and 4 that instance is not serving. With one replica, that is an outage; with many, it is a replacement to be sequenced. None of that applies to the file shape, which is exactly why a large or frequently-adjusted document tends to end up as a file. ## Reading the symptom correctly The everyday version of this is "I changed the value and nothing happened". Before blaming the platform, separate three claims that are often collapsed into one: - **The declared value changed.** Check what the platform now holds, not what someone typed. - **A new process was created.** If the instance has been up longer than the change, it cannot be using it. - **The process read the value it was handed.** A process that reads a setting once at start-up and caches a derived object will not notice even a file change without doing something about it. Those are three different failures with three different fixes, and only the second one is decided by the delivery shape. ## The trade this sets up | | inherited set | mounted file | |---|---|---| | where the live bytes are | inside the process | in the filesystem | | can the platform change them under a running process | no | yes | | what a change costs | a new process for that instance | a write, with no process churn | | what is guaranteed about consistency | the set is fixed for that process's whole life | the file may differ from the copy the process parsed | That last row is the real trade. The inherited shape gives you something valuable: a process's configuration cannot shift beneath it mid-flight, so a value read at start-up and a value read an hour later are the same value. The file shape gives that up in exchange for changeability. What a process then does about a file whose bytes have moved — whether it notices, when, and how long the platform takes to make the new bytes visible — is a separate subject with its own failure modes.

  • If a process can rewrite its own environment, why is that not a way to deliver a new value?
    Because the process has to already know the new value to write it, which is the problem you started with. Self-modification only decides what the process's future children inherit. It also means an inspection of a live process is not proof of what the platform delivered — the two can legitimately differ.
  • Does a mounted file guarantee the running process is using the current value?
    No. It guarantees the *source* is current. A process that opened the file once at start-up and parsed it into memory holds a copy that is exactly as stale as a variable would be. The file shape makes freshness possible; it does not make it automatic.

saying these in an interview costs you the question

  • The platform can push a new variable into a running process
  • Restarting the container is a workaround, not the mechanism
  • A changed mounted file is automatically in use by the process
  • Variables and files both need a restart to take effect
  • The value in the spec is what the running process is using