Open Blaisorblade opened 8 years ago
I'd like to avoid needing the Docker image to contain anything special (like dumb-init or tini), because that makes it harder to use arbitrary images (like the official Haskell images). Also, in my experience, those init processes tend to interfere with Stack's somewhat complex re-launching of itself in a container (although I haven't tried either dumb-init or tini).
Rather, stack
can act as its own init process (basically detect that it's pid 1 in a container and if so fork itself and let the original process just reap zombies).
Rather, stack can act as its own init process (basically detect that it's pid 1 in a container and if so fork itself and let the original process just reap zombies).
Are you describing existing code or suggesting that somebody writes it?
The code doesn't exist yet. It's what I was thinking of implementing.
Sounds doable though not immediate. tini is ~500 lines of subtle C (which might have more than we need) (https://github.com/krallin/tini/blob/master/src/tini.c); dumb-init is ~300 lines (https://github.com/Yelp/dumb-init/blob/master/dumb-init.c). At least if all libraries have wrappers (which sounds plausible).
My 2 cents: I'd say make it a lib (exposing initMain :: IO ()
) that can be linked in stack and used externally (with main = initMain
), so this can be leveraged elsewhere.
@borsboom wrote:
I agree. IMHO Docker images should always use a proper init process. Even if you run GHC directly:
Minimal init binaries include dumb-init (used in the past by @snoyberg) and tini (used by me). I'll favor the smallest/most portable/possibly statically linked one.
2474 was about a container launched manually, but IIUC the issue is still there for Stack Docker containers (to verify).