Red Hat Bugzilla – Bug 1312422
installing the custom CA cert from satellite 6 results in restarting a running docker service
Last modified: 2017-09-16 01:42:16 EDT
Description of problem:
When preparing to register a content host, installing the custom CA from the satellite via # rpm -Uvh http://sat6.lyletech.lab/pub/katello-ca-consumer-latest.noarch.rpm will restart a running docker service, resulting in any containers running on that service to stop
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1)Configure docker repo
# sudo tee /etc/yum.repos.d/docker.repo <<-EOF
2) install docker
# yum install docker-engine
3) start the service
# systemctl start docker.service
4) install the ca from satellite 6
# rpm -Uvh http://sat6.lyletech.lab/pub/katello-ca-consumer-latest.noarch.rpm
The docker daemon is restarted, and all running containers are stopped as a part of that
Feb 26 07:32:25 localhost systemd: Stopping Docker Application Container Engine...
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.834120906-05:00" level=info msg="Processing signal 'terminated'"
Feb 26 07:32:25 localhost systemd: Stopping Docker Socket for the API.
Feb 26 07:32:25 localhost systemd: Starting Docker Socket for the API.
Feb 26 07:32:25 localhost systemd: Listening on Docker Socket for the API.
Feb 26 07:32:25 localhost systemd: Starting Docker Application Container Engine...
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.902235735-05:00" level=warning msg="devmapper: Usage of loopback devices is strongly discouraged for production use. Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to dm.thinpooldev section."
Feb 26 07:32:25 localhost systemd: Device dev-disk-by\x2duuid-520e3171\x2dc715\x2d42b8\x2d8d75\x2dbeeaa17b2cdd.device appeared twice with different sysfs paths /sys/devices/virtual/block/loop0 and /sys/devices/virtual/block/dm-1
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.911991914-05:00" level=warning msg="devmapper: Base device already exists and has filesystem xfs on it. User specified filesystem will be ignored."
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.915409421-05:00" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.915694159-05:00" level=info msg="Graph migration to content-addressability took 0.00 seconds"
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.924557829-05:00" level=info msg="Firewalld running: false"
Feb 26 07:32:25 localhost docker: time="2016-02-26T07:32:25.959092750-05:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002059141-05:00" level=info msg="Loading containers: start."
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002096026-05:00" level=info msg="Loading containers: done."
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002103382-05:00" level=info msg="Daemon has completed initialization"
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.002112994-05:00" level=info msg="Docker daemon" commit=c3959b1 execdriver=native-0.2 graphdriver=devicemapper version=1.10.2
Feb 26 07:32:26 localhost systemd: Started Docker Application Container Engine.
Feb 26 07:32:26 localhost docker: time="2016-02-26T07:32:26.006647271-05:00" level=info msg="API listen on /var/run/docker.sock"
Would not expect the rpm to restart a running service
rpm -qp --scripts katello-ca-consumer-latest.noarch.rpm
# restart docker if it is installed and running
if [ -f /usr/lib/systemd/system/docker.service ]; then
systemctl status docker >/dev/null && \
systemctl restart docker >/dev/null 2&>1
elif [ -f /etc/init.d/docker ]; then
service docker status >/dev/null && \
service docker restart >/dev/null 2&>1
Perhaps remove this behavior from the RPM, and we could update the docs telling users they will need to restart the docker service prior to being able to build containers with Satellite?
Is there a better behaviour? I ask because without the restart, the docker client will not against the satellite.
(In reply to Bryan Kearney from comment #1)
> Is there a better behaviour? I ask because without the restart, the docker
> client will not against the satellite.
Agreed, but this restart of the service should be in the users hands IMO, not automated through a seemingly innocuous action. I also have a docs BZ open to at least warn the users of such action.
Perhaps a combination of removing the automated restart and letting the users know what a restart of the service is required prior to using docker from the sat?
Any reason why this ticket is internal only?
Created redmine issue http://projects.theforeman.org/issues/19271 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19271 has been resolved.
We tried to migrate satellite clients from 6.2.8 to 6.2.10 and it did affect the production environment. Any timeline on the fixure please?