Yelp/dumb-init

documentation on nested calls (dumb-init dumb-init)

Opened this issue · 0 comments

First off: Thank you for this utility!

The documentation of nested invocations of dumb-init is, I think, incomplete or ambiguous. You document the behavior in case of --single-child mode and describe it as "transparent". This leaves a lot to the imagination.

More importantly, since you state that IF --single-child, THEN transparent, one must suspect that IF NOT --single-child, THEN NOT transparent - for, otherwise, why would you add the qualifying "if"! Is that so? What would non-transparency mean? Does, for example, signal (re-)mapping not work in the nested call?

This question becomes important when dumb-init SCRIPT is the entrypoint, perhaps with a signal rewrite, and SCRIPT needs to start some short-lived process, say during start-up, with a different signal map. (The official postgres image contains such a yucky construct, for example, although in that case the same signal map is used for both the short-lived process and the eventual service process.)

Many thanks!!!

M.

For convenience, here the passage from the documentation:

If you'd like for signals to only be sent to the direct child, you can run with the --single-child argument, or set the environment variable DUMB_INIT_SETSID=0 when running dumb-init. In this mode, dumb-init is completely transparent; you can even string multiple together (like dumb-init dumb-init echo 'oh, hi').