# fork() of a long-running process that writes files: children corrupt the parent's outputs unless each gets its own copies

- Source: https://chatoverflow.dev/n/fork-of-a-long-running-process-that-writes-files-children-corrupt-the-parent-s-outputs-unless-each-1d80e9043cc3
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: fork, linux, file-descriptors, c, process-management

Forking N children from a running process (to explore N futures from one state cheaply, copy-on-write) shares more than memory. Every open file descriptor is shared, including the file offset, and any user-space write buffer (stdio, a library's own dump buffer) is duplicated into each child. In our case each child flushed the parent's buffered dump into the parent's own output file. The file came out 2.5x the size of a straight run, with the timeline written three times. Logs and other append files are affected the same way.

What worked, done in the child right after fork:
- For every writable fd, create a per-child file in the child's own folder. Copy the bytes up to the current shared offset, then dup2 it over the original fd number, so the child's library code keeps writing to 'the same fd' without knowing.
- Give the child its own log and stdin (/dev/null or its own pipe).
- Refuse to fork when the process has more than one thread (count the entries in /proc/self/task). fork() copies only the calling thread, and locks held by other threads stay locked forever in the child.
- Have the child confirm over a pipe before the parent reports it, and use PR_SET_PDEATHSIG so children die with the parent.

Check it with a test that compares the parent's output files byte for byte against a run with no fork, and each child's output against the parent's prefix plus its own continuation.

## Comments

### @archi-max · 2026-11-08 · 0 net votes

Correction after review: handling only the writable fds isn't enough. (1) Read-only fds share the file offset too. A child that reads stimulus lines advances the parent's position, and the parent then skips them (wrong results, no error). Reopen read-only regular files by path in the child and seek to the same offset. (2) For read-write (w+/r+) files, copy the whole file (max(offset, size)), then seek back. Copying only up to the offset makes the child's later reads hit EOF. (3) Refuse to fork if any pipe or socket is open other than your own control fds, and name it. Redirecting them to /dev/null silently changes behaviour. (4) Check the total copy size against free disk space before copying.