Podman: RFE: Add support for podman run --init

[bowlofeggs]

Is this a BUG REPORT or FEATURE REQUEST?:

Description

docker run has an --init flag that replaces process 1 with a minimal process that performs basic signal handling and child management. It would be nice if podman run had this feature as well.

[mheon]

We include some of the functionality of the minimal tini init already in Conmon (process reaping, for example). Generally we prefer to use systemd for cases where a more powerful init system is required (we have excellent native support for containerized systemd built in), but I don't see anything wrong with including this as an option (I wouldn't want to force tini as a dependency of Podman though)

[vrothberg]

I have no strong feelings for nor against the proposal. @baude, @rhatdan WDYT?

[rhatdan]

I actually do not believe we need this, since conmon provides this behaviour now, I believe.

conmon will reap at container process zombies.

@giuseppe WDYT?

[giuseppe]

conmon won't be able to reap processes created inside the PID namespace, zombie processes are reparented to PID 1 in the namespace.

The reaper part of conmon is only to cleanup processes left around by the OCI runtime. This is required as conmon sets itself as a reaper to be able to read the container process exit code

[rhatdan]

Does runc have some magic to make this happen? or does docker just run a container with a static init volume mounted into it and then execs the command? Or does the init take an option of the first command to fork/exec?

[rhatdan]

@mrunalp @runcom WDYT?

[giuseppe]

runc doesn't have any magic AFAIK, we will need to go the ugly way of mounting a static binary inside the container (this is what Docker does, it is mounted as /dev/init) and use it to boot the real application.

It could be a minimal static C program we ship together with conmon.

[rhatdan]

Makes sense.

[vrothberg]

@cyphar wrote https://github.com/openSUSE/catatonit that does the job very well.

[rhatdan]

That works for me. @giuseppe WDYT? Do we need this as a separate package?

[giuseppe]

that is exactly what I had in mind, it works for me.

Just out of curiosity, what are the differences with tini?

Now the difficult question is how to distribute it. I think we could add it to the conmon .rpm once we have it?

[vrothberg]

That works for me. @giuseppe WDYT? Do we need this as a separate package?

You can find the package sources for openSUSE here. I think that a separate package makes sense as it can be used for Docker as well (which is what we did for openSUSE/SLES).

[cyphar]

Just out of curiosity, what are the differences with tini?

catatonit is significantly simpler (taking up 50% sloc), and it correctly handles signals. tini does this weird thing with sigtimedwait rather than reaping on SIGCHLD -- catatonit uses signalfd which is more correct and slightly more modern. There was a theoretical race I found in tini which catatonit is resilient to (but I don't recall the details, this was a while ago).

You might wonder why I didn't just submit a patch. The problem is that switching to signalfd would be equivalent to a full rewrite (since the program's only job is signal handling). And while I wouldn't mind submitting it, I have a feeling this would feel like an insult to the current developers of the project -- submitting a rewrite of the only major thing it does.

[rhatdan]

@giuseppe @vrothberg Any movement on this issue?

[vrothberg]

I don't think so but I can look into it.

[vrothberg]

Thanks for catching up, @rhatdan :)

[giuseppe]

no, nothing done here. Will podman be the only consumer of catatoinit? If so, it probably makes sense to add to the podman .rpm itself

[rhatdan]

Yes lets make it part of the package, we don't want to support it independantly, especially in RHEL.

[muayyad-alsadi]

sorry to bump this up,
nothing provides this binary in fedora

# podman run --init -ti busybox /bin/sh
Error: container-init binary not found on the host: stat /usr/libexec/podman/catatonit: no such file or directory
# dnf provides '*/catatonit'
Error: No Matches found

on the other hand with docker it just work because /usr/libexec/docker/docker-init-current is shipped as part of docker package

# rpm -qf /usr/libexec/docker/docker-init-current
docker-1.13.1-63.git1185cfd.fc28.x86_64

shouldn't we ship catatonit and make it a dependency or at least a soft dependency?

[mheon]

@lsm5 ^^

[mheon]

I know we talked about packaging this up, but I'm not sure what happened with that.

[vrothberg]

It's in the pipeline but other tasks had a higher priority. In the meantime, libpod.conf and the CLI flags allow using another init binary as a temporary workaround.

[kurobeats]

It's in the pipeline but other tasks had a higher priority. In the meantime, libpod.conf and the CLI flags allow using another init binary as a temporary workaround.

Where can we find the workaround?

[muayyad-alsadi]

Where can we find the workaround?

you can pass any init using podman run --init-path= like dumb-init.

also in libpod.conf there is a line for init_path=""