fix(child_process): fix inverted break condition in close method

[magic-peach]

Summary

In the close method's wait-for-exit loop (lib/fluent/plugin_helper/child_process.rb:194), the condition break if living_process_exist is inverted and should be break unless living_process_exist.

The bug

The loop is designed to wait for all child processes to exit (or force-kill them after the kill timeout). The logic:

1. Check all tracked pids
2. If a process is still alive, set living_process_exist = true and force-kill it if past the timeout
3. break if living_process_exist — this is backwards

The current code breaks out of the loop as soon as it finds any living process, immediately proceeding to super and continuing shutdown without waiting for those processes to actually terminate. This allows child processes to become orphaned or zombie processes.

Comparison with shutdown method

The shutdown method (line 142) correctly implements the same wait-for-exit pattern:

if process_exists
  sleep CHILD_PROCESS_LOOP_CHECK_INTERVAL
else
  break
end

The close method should follow the same pattern: keep looping while processes are alive, break when they're all gone.

[Watson1978]

I looked into the history before reviewing, and I believe this condition is intentional rather than an inversion. break if living_process_exist was introduced in commit 39b9060 ("fix bug to never break loop", 2016). Before that change, close was a plain while pids.size > 0 loop that could fail to terminate; the living_process_exist tracking and break if living_process_exist were added specifically to guarantee the loop always exits.

The key difference from shutdown is the loop bound. shutdown's wait loop is bounded by exit_wait_timeout:

while Fluent::Clock.now < exit_wait_timeout

so "keep looping while a process is alive" is safe there. close has no such bound. Changing it to break unless living_process_exist turns close into an unbounded "loop while any process is alive," which reintroduces exactly the non-termination bug that 39b9060 fixed: if a child can't be reaped, shutdown would hang indefinitely.

Could you share a reproduction of the orphan/zombie behavior? With that we can work out the right bounded fix. As it stands I don't think we can flip this condition, since it would re-open the 2016 hang.