podman-nginx-socket-activation VS conmon

https://github.com/eriksjolund/podman-nginx-socket-activatio...

I wrote an nginx socket activation example https://github.com/eriksjolund/podman-nginx-socket-activation (The example does not show nginx working as HTTP reverse proxy but I think tried that out before and it worked)

(I wrote a demo: https://github.com/eriksjolund/podman-nginx-socket-activation)

The difference is that with Podman its possible to create a systemd socket unit for the service (for example nginx.socket).

The problem when running rootless Podman with socket activation and docker.io/library/nginx is caused by the closing of file descriptor 3 in /entrypoint.sh.

It is an open-source, community-driven project which supports OCI-based container registries. It is being maintained by contributors working in Red Hat, Intel, etc. It also comes with a monitoring program known as conmon. Conmon is an OCI container runtime monitor, which makes the communication between CRI-O and runc for a single container.

When considering using socket activation it's good to know that socket-activation has the advantage that you can create on-demand services. And in the future you might be able to do container image upgrades without loosing an active TCP connection https://github.com/containers/conmon/issues/393 (Right now it's just a feature request that I wrote).

This was a wrong assumption. Podman directly uses runC or crun instead of containerd using a technology named conmon. Some more useful information can be found in this article.

Well, "daemonless" is kind of marketing - there is still this daemon-per-container 'conmon' thing https://github.com/containers/conmon and I don't get why it is needed because 1) who actually needs to re-attach anyway? 2) container's streams are already properly handled by whatever supervisor (e.g. systemd). You can't disable conmon and I'm not sure if its usage is not hardcoded throughout the codebase.

I would very much like to use Podman as a finally proper container launcher in production (non-FAANG scale - at which you maybe start to need k8s), but having an unnecessary daemon moving part in thousands lines of C makes me frown so far.