use s6-overlay with shared PID from docker host

[mhdali]

Hello,

When we use s6-overlay with --pid=host it stop all the system processes including Docker one!

I think it will be better if there is an environment to skip stopping all container processes, but in this case we have to explicitly create a stop script to shutdown the container with it's processes.

[jprjr]

Is this still an issue? What's the use-case for --pid=host?

[frenck]

I have a similar issue. However, I work around it by making s6-nuke a NOOP:

https://github.com/hassio-addons/addon-glances/blob/main/glances/rootfs/bin/s6-nuke

The use case is for containers needing to share the PID space with the host of course, for example, for monitoring tools like Glances. Without sharing the PID namespace with the host, it would only monitor the processes in its own container.

[jprjr]

I'll just be brutally, brutally honest. I feel like every little thing I do on this project breaks something for somebody, I don't really enjoy working on it anymore.

If there's a work-around for a container that depends on --pid=host, I'd vote to just do that.

The alternatives off the top of my head:

• Create another environment variable that disables calling s6-nuke. But once you're at the point that you realize you don't want s6-nuke, you probably building something where you'll want to replace it with a no-op anyway (because what if a downstream user doesn't set the environment variable and brings their whole host down?)
• Remove the s6-nuke steps entirely. Odds are for a lot of use-cases, we could probably just run the cont-finish scripts, send the sigterm to s6-svscan, wait a bit, then exit and let Docker clean up everything else. But odds are, somebody's got something that relies on s6-nuke sending that earlier TERM signal to all the processes.
• Maybe we disable s6-nuke by default, have an environment variable to enable it if-needed.

[frenck]

I'll just be brutally, brutally honest. I feel like every little thing I do on this project breaks something for somebody, I don't really enjoy working on it anymore.

Sorry, to hear that. I appreciate your work. I don't need it, and I don't care if something for this is added or not. I just tried to be friendly and provide a friendly bit of context when I saw the issue, especially since you actually asked for it.

Looking back, doing that seems like a bad idea. I Will definitely not do that again on this project.

[skarnet]

s6-overlay 3.0.0.0 is out, which should be a lot easier to maintain now and break fewer things for everyone. :-)

That said, unfortunately, --pid=host is not something we want to support. This is antithetical to the concept of containers; we assume containers run in a separate pid namespace. To ensure proper container shutdown, killing all processes before exiting is necessary; this causes problems for --pid=host installations, but it's because these installations are not proper container setups.

Sorry, but I have to close this as WONTFIX.

[frenck]

because these installations are not proper container setups.

Right... Hence the option exists 🤷

Anyways, thanks for responding 👍

[frenck]

s6-overlay 3.0.0.0 is out

Where?

[skarnet]

The option exists in Docker because Docker likes to have a lot of features; that does not mean that every single one of these features is a good idea to use. By using --pid=host, you are essentially negating most of the benefits of containerization, which impacts the security of your host machine. Use at your own risk.

v3.0.0.0 is still lacking CI/CD, so there aren't yet any pre-built tarballs; they will come in the next days/weeks. For now, you can download from source and build the overlay yourself - it's as easy as typing make. ;-)

[frenck]

The option exists in Docker because Docker likes to have a lot of features; that does not mean that every single one of these features is a good idea to use.

I agree, you don't have to support it either :) I was honestly thanking you for responding and handling. Won't fix is an answer that is acceptable.

you are essentially negating most of the benefits of containerization

Yeah, there are some small corner cases where this is useful. But agree, it should bu avoided as much as possible.

v3.0.0.0 is still lacking CI/CD, so there aren't yet any pre-built tarballs; they will come in the next days/weeks. For now, you can download from source and build the overlay yourself - it's as easy as typing make. ;-)

👍 I'll await the official builds. Thanks for tagging!