At the moment I’m getting message "no response from daemon: shim error; docker.runc not installed on system".
I tried a possible solution for that to no avail
Earlier today I installed telnet (which I guess updated yum?) to troubleshoot an email issue. Right now, I’m kinda hosed. I’m on Centos 7 I believe. Initially docker would not start, stated a problem with the network bridge. Removed and installed docker from yum to get that working again.
Containers = 0 kinda concerns me, although I did make a backup of my docker directory before messing around. I did run docker rm app at one point (After the error about docker-runc occured)… maybe not such a good idea.
Attempt to rebuild results in same error message regarding docker-runc
For some reason, Docker doesn’t seem to play well with CentOS. Most of us here use Ubuntu, so don’t have solutions off the top of our heads. If you’re stuck and just want someone to fix it, I’ll figure out something. You can place an order here: Fix Your Broken Site – Literate Computing, LLC . I’ll just fix what you’ve got rather than re-installing the OS as described there, though if you’d be willing to switch to Ubuntu, I could switch you over for the same price if Discourse is all that’s running there.
If systemd says “disabled”, you have multiple options
systemctl enable docker
SELinux is causing fun
this is a meta unit which is disabled. The real service is named differently. You can see that for example with Elasticsearch, where the service unit files are named differently for each cluster instance.
Let’s do this in a CentOS Vagrant VM (actually, it is icinga-vagrant/icinga2x with a stopped httpd)
yum install -y yum-utils \
yum -y install docker-ce
systemctl enable docker.service
systemctl start docker.service
git clone https://github.com/discourse/discourse_docker /var/discourse
<enter all the time, let it fail at the end with the defaults, I have special requirements here>
Bootstrap afterwards works then.
[root@icinga2 discourse]# ./launcher bootstrap app
which: no docker.io in (/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/root/bin)
WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed
Please be patient
This also works for me with setenforce 1 as the Docker package installs an SELinux policy.
So this somehow seems to be related to the missing enable/start step on CentOS. No need for a migration run to Ubuntu imho.
Systemd starts dockerd here, you can see that from the service file in /lib/systemd/system/docker.service:
Description=Docker Application Container Engine
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
# set delegate yes so that systemd does not reset the cgroups of docker containers
# kill only the docker process, not all processes in the cgroup
# restart the docker process if it exits prematurely
Do you have any other occurrences of a Systemd service file for docker, e.g. in /etc/systemd?
Anyhow, I’d suggest to start “fresh”. Purge anything which has docker in its name from the system
This appears to be the key. I did go though and remove as many docker-xxx packages as I could think of earlier, and it made no difference.
This time, docker installed and started after I ran the find lines.
Discourse is updating it’s base now… We’ll she
I was (still am) pondering moving to ubuntu purely because my exisitng setup on centos seems to be very fragile. Anytime I try to update discourse, I end up with a broken container, or a docker that won’t start.
Probably Although I would had to move all my data across and I’m not sure how involved that would be.
I was doing both really. Alternating between working on ubuntu and this centos install. Hit a snag with docker under ubuntu on the same hosting. Went through signup process with another host, docker and discourse was simple, but email with sendgrid is not co-operating for some reason
I’m a friend of solving immediate issues, they give you some experience with debugging things, and also the obligatory “yes, I solved it” feeling.
I see that in the monitoring community a lot. Problem X is there, doesn’t work. Another user jumps in and suggests to replace it with project Y. Keeping a question with a discussion and a possible solution helps many others who find the topic years after with Google. I do see my knowledge input as investment into the future, not to answer that again and again.
Still, if many community members choose Ubuntu LTS, go for it. You are now in the first steps where such a decision can be made easily. At NETWAYS, we’re also going the Ubuntu route these days, and my Discourse instance runs on 14.04 at the moment. dist-upgrade to 16.04 is planned, 18.04 will be out this year too.
The good thing about the container image is that you don’t have to care about Ruby, gem, etc. version dependencies. In terms of security aspects in such an AIO package, I do have the feeling that the Discourse team acts responsible with announcing and forcing users to upgrade on possible CVEs and security bugs.
True, and sendgrid is one that offers this. I wasn’t seeing any requests hit sendgrid (It will show attempts from IPs not on the approved list in the dashboard), yet was able to telnet to the smtp server, so it wasn’t a firewall issue either.
In the end, started over with a separate account sendgrid account, a fresh API key and it’s happy now.