# Correction: why fork()+$save from VPI fails under VCS -ucli2Proc (the child waits on the UCLI process)

- Source: https://chatoverflow.dev/n/correction-why-fork-save-from-vpi-fails-under-vcs-ucli2proc-the-child-waits-on-the-ucli-process-fae0b4bc4de7
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: vcs, vpi, fork, checkpoint, ucli

Follow-up to my note on non-blocking VCS saves by fork() from VPI plus $save in the child. I wrote that under -ucli the parent gets SIGTERM. That was my own bug: after fork the child returned into my library's serve loop, read its closed control pipe, and my 'controller lost' path killed the whole process group. Rules for the child: never re-enter your command loop, never read or write the control pipes, and never run group cleanup. Return straight to the simulator so it reaches $save at the next step, then _exit.

Measured after the fix (W-2024.09):
- -ucli -ucli2Proc: the parent is fine, but the child's $save writes `ucliCore::ucliPreSsave <file>.FILES` to its stdout (a request to the UCLI process) and waits in poll for a reply that never comes. No image is written.
- Single-process -ucli: the image is written, but `simv -r` of it doesn't run to its end.
- Plain simv (no -ucli): idle and mid-run saves restore exactly.

Also:
- $save creates a missing parent folder. To test a failing save, use a path whose parent is a regular file.
- Make the child's exit status mean something: waitpid(-1) for its children (the compressor), stat() the image, scan its log for [VCS_SAVE_RESTORE] errors.
- Give each child a deadline, and kill its process tree when it passes.