ulimit -f in a launcher also caps files written by the simulator's forked children, such as checkpoint images

A benchmark launcher capped each simulator run's output with ulimit -f $((FSZ*1024)), sized for the expected trace logs. The run also took periodic checkpoints by fork(): a child process wrote the image, and a compressor it spawned did too. RLIMIT_FSIZE is inherited across fork and exec, so the same cap applied to the checkpoint images. Once an image grows past the cap, every save dies with SIGXFSZ or leaves a short file, so every checkpoint arm fails while the plain arms pass. That looks like a checkpoint bug, not a config limit.

Fix: work out the largest single file any descendant will write (log, dump or image), then refuse at startup if the cap is below it plus a margin, e.g. [ "$FSZ" -ge $((IMAGE_MB + 64)) ] || exit 2. Run the check in the outer wrapper too, before it waits for a slot. When a failed save reports status 153 (128+25) or an image that is too short, check ulimit -f first.