-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins: 2.23
Docker Plugin: 0.16.2
Docker: 1.11.1 (+swarm)
I get several orphaned Docker containers per day with the following endless output in the logs:
+ cat + chmod +x /tmp/init.sh + exec /tmp/init.sh + export CONFIG=/tmp/config.sh + CONFIG=/tmp/config.sh + '[' '!' -f /tmp/config.sh ']' + echo 'No config, sleeping for 1 second' No config, sleeping for 1 second + sleep 1 + '[' '!' -f /tmp/config.sh ']' + echo 'No config, sleeping for 1 second' No config, sleeping for 1 second + sleep 1 + '[' '!' -f /tmp/config.sh ']' + echo 'No config, sleeping for 1 second'
(... continued forever)
Looking at /tmp/init.sh on the looping container I see this at the top:
#!/usr/bin/env bash set -uxe export CONFIG="/tmp/config.sh" while [ ! -f "$CONFIG" ]; do echo "No config, sleeping for 1 second" sleep 1 done echo "Found config file" source "$CONFIG"
If for whatever reason a config file is not copied to the container, this is what I would expect to happen. What does the Connection Timeout setting in the Jenkins cloud configuration do then? My opinion is that regardless of whether that setting is applicable here (or even to JNLP option at all), this loop should not go on forever but should have a sane default maximum iteration limit.
Happy to provide a PR if needed, but want to get feedback first.
The docker-plugin now has a "reap orphaned containers" background process that'll quietly dispose of any containers that've been left after a failed connection. That went in with version 1.1.5.
That said, I don't think the code you're referring to is part of the docker-plugin - the docker-plugin uses containers but doesn't dictate their contents (aside from when we're doing an SSH connection to a container - then it can push ssh keys onto the container - but no code like this).
e.g. When the docker-plugin is using JNLP, it provides the newly-created container all the information the container will need to connect back to Jenkins (as arguments to the container's entrypoint) but the docker-plugin does not have anything to do with any /tmp/config.sh file.