Forking a restored process: trusting inherited fds by number (3/4) misclassifies a launcher's fds; constructors can also run twice across a self re-exec

Context: a tool forks a running (or checkpoint-restored) native process and decides, fd by fd, what each child keeps: reopen read-only files, copy writable ones, detach its own channels, and refuse anything shared that it does not recognise.

Lesson 1: do not identify your own channel by fd number. One rule said: in a restored run, fds 3/4 are our old worker channel, so detach them silently. I restored a checkpoint by hand from a launcher that had its own sockets on fds 3/4, and the clone reply marked both as worker channel and auto-detached them. The refuse-unless-opted-in rule was bypassed. fds 3/4 are common for other things too (make jobserver --jobserver-auth=3,4, CI runners, test harnesses). Fix: record the channel identity (st_dev/st_ino of the socket, or the peer) when the checkpoint is made and match on that, or apply the rule only when an env marker set by your own launcher is present. Otherwise treat the fd as unknown. To test, spawn the restore with stdio [ignore, pipe, pipe, pipe, pipe] from a different parent and read the clone reply.

Lesson 2: some native programs re-exec themselves at start (same pid, two execve calls in strace -f -e trace=execve). Shared-library constructors then run once per image. Any fd a constructor opens without O_CLOEXEC/SOCK_CLOEXEC survives into the second image, so you see the resources twice (one socketpair became 4 sockets). Check with a constructor that logs getpid() and an fd count to a file named by an env var. Guard with an env marker, or use CLOEXEC.

Lesson 3: a /proc/self/maps scan for rw-s lines catches every shared writable mapping kind in one check: file MAP_SHARED with its fd closed, anonymous MAP_SHARED (shows as /dev/zero (deleted)), SysV shm after IPC_RMID (/SYSV... (deleted)), and memfd (/memfd:name (deleted)). Test all four, plus one made by a constructor before your library loads. r--s mappings still see later writes made through the file, so note that.

Lesson 4: if you give a forked child fresh (truncated) copies of write-only outputs, any output with a header written once at start (waveform dumps, CSV with a header row) is invalid in the child. Copy those files, or document it.