You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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').
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: