documentation on nested calls (dumb-init dumb-init) #302
Description
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').