Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container autodetect fails when not running in docker #2143

Closed
SniperCZE opened this issue Nov 19, 2018 · 3 comments
Closed

Container autodetect fails when not running in docker #2143

SniperCZE opened this issue Nov 19, 2018 · 3 comments

Comments

@SniperCZE
Copy link

@SniperCZE SniperCZE commented Nov 19, 2018

Passenger looks for existing of .dockerenv file to check if running in container:

return fileExists("/.dockerenv");

Not all containers are docker, we have LXC/LXD here and this check will fail on it. You should use multiple checks, like environment variable container (see https://stackoverflow.com/questions/20010199/how-to-determine-if-a-process-runs-inside-lxc-docker/20010626#20010626) to determinate if passenger is running inside container.

Steps to reproduce:

  1. Run passenger in another container environment than docker
  2. Call autoDetectInContainer() function

Actual result:
False is returned

Exceptected result:
True is returned

@CamJN
Copy link
Contributor

@CamJN CamJN commented Nov 19, 2018

I agree that the existing check is definitely too docker specific. Being somewhat less familiar with LXC/LXD I wonder if you could confirm some things for me.

Do LXC/LXD containers prevent modifying the OOM score of processes in the container?
What are the contents of /proc/1/cgroups in your container?
Is the container envvar the official method of determining containerization status of an LXC/LXD container? Are there docs anywhere to this effect, or is it an unofficial standard?

Thanks!

@SniperCZE
Copy link
Author

@SniperCZE SniperCZE commented Nov 20, 2018

OOM score cannot be adjusted if unprivileged container. it is hard kernel limitation - unprivileged container cannot set higher than current value to prevent users start unkillable processes (unprivileged containers can be started by normal users).

I don't know if container envvar is official way to detect, but it works. Content of /proc/1/cgroup is not reliable anymore, at least for LXD on Ubuntu 18 is same for container and host. Systemd has systemd-detect-virt util, which can detect multiple virtualisation technology, maybe you should look over their solution (I believe systemd is reliable source of kernel hacks).

CamJN added a commit that referenced this issue Dec 3, 2018
CamJN added a commit that referenced this issue Dec 3, 2018
@CamJN
Copy link
Contributor

@CamJN CamJN commented Dec 3, 2018

Can you build and test the GH-2143_container_autodetection branch under your setup? I've implemented the logic from the systemd container detector more or less.

CamJN added a commit that referenced this issue Dec 12, 2018
@CamJN CamJN closed this in 2165cb3 Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants