libuv icon indicating copy to clipboard operation
libuv copied to clipboard

Add LIBUV_INIT_REAPER environment variable

Open giannitedesco opened this issue 2 years ago • 1 comments

This controls whether to enable the behaviour of reaping all child processes. This is useful in the case where libuv is being used as part of a pid-1 or init process as it allows us to reap orphaned children that we have not, ourselves, spawned.

In order not to change the semantics for cases where we are possibly interacting with other libraries and the like, control this behaviour with a new environment variable LIBUV_INIT_REAPER. The possible values are:

  • LIBUV_INIT_REAPER=always - always reap unknown processes
  • LIBUV_INIT_REAPER=init-only - reap unknown processes if we are pid 1
  • unset or all other values - same as before

This re-raises the issue of #3199 which was reviewed by @vtjnash - rather than address exotic new functionality with tracing of child processes, just make the functionality opt-in with an environment variable. This way a program author can chose to opt in to it by modifying the env block, or a container packager can opt in to it, without making any code changes, by just adding an environment to the Dockerfile (or equivalent).

giannitedesco avatar May 16 '22 02:05 giannitedesco

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

stale[bot] avatar Jul 10 '22 12:07 stale[bot]

This PR doesn't merge cleanly and I don't feel using environment variables is appropriate. I'm going to close this but thanks anyway.

bnoordhuis avatar Oct 21 '23 11:10 bnoordhuis

@bnoordhuis no problems, I plan to update it soon but... if the env var is no good is there any other form that would be acceptable? Perhaps it needs some API for setting the reaping policy?

giannitedesco avatar Oct 21 '23 14:10 giannitedesco

Maybe open an issue first, to discuss whether it's a feature we would want to adopt (and support.)

FWIW, I'm personally leaning towards "no" but maybe other maintainers feel differently.

bnoordhuis avatar Oct 22 '23 09:10 bnoordhuis