Installation failing on CentOS 7.3

I’ve never had a problem running Discourse on CentOS in the past, but I’m suddenly unable to build it for some reason on a new CentOS 7.3 EC2 instance.

While building, the errors begin with:

I, [2017-03-02T05:29:38.051256 #13]  INFO -- : > cd /var/www/discourse && chown -R discourse /var/www/discourse
chown: cannot access '/var/www/discourse/app/assets/javascripts/discourse/helpers/max-usernames.js.es6': No such file or directory
chown: cannot access '/var/www/discourse/lib/locale_file_walker.rb': No such file or directory

…and the build fails with:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && chown -R discourse /var/www/discourse failed with return #<Process::Status: pid 275 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"web", "cmd"=>["gem update bundler", "chown -R discourse $home"]}

Although not my usual approach, I followed the supported directions and continued to get identical errors. Here are the supported steps I’ve used on CentOS 7.3 with Docker 1.13.1 (build 092cba3) to reproduce the errors:

mkdir /var/discourse
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

As usual I suspect Docker issues. Notorious under Red Hat or clones. What filesystem is being used? docker info and all that.

Does Discourse on CentOS 7.3 help you at all?

1 Like

Hmm. All my Dockerfiles play well with CentOS, but maybe that’s because I develop against RHEL-type distros exclusively.

Maybe. This didn’t show up when I searched, but looks promising. What does “ftype” refer to? My dump and fsck values are both 0.

cat /etc/fstab:

UUID=ef6ba050-6cdc-416a-9380-c14304d0d206 /                       xfs     defaults        0 0

This is the officially-supported AMI on AWS, by the way.

Do you ever do a chmod, chown, or similar in your Dockerfile? Most dockerfiles I’ve seen do absolutely everything as root, so they don’t hit this particular bug.

It’s a filesystem-creation-time option. According to the source post:

So what does docker info have to say on your system?

1 Like

Nope.

My docker info shows that d_type support is not enabled.

[root@ip-172-31-60-203 discourse]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.13.1
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-514.6.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.451 GiB
Name: ip-172-31-60-203.ec2.internal
ID: 24CD:XYZA:QWO7:N3IL:DJVP:4KB3:AM4M:EFI7:WEQL:KHVD:JB2Z:ZGRZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
[root@ip-172-31-60-203 discourse]# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
[root@ip-172-31-60-203 discourse]# nano /etc/fstab
[root@ip-172-31-60-203 discourse]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.13.1
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-514.6.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.451 GiB
Name: ip-172-31-60-203.ec2.internal
ID: 24CD:XYZA:QWO7:N3IL:DJVP:4KB3:AM4M:EFI7:WEQL:KHVD:JB2Z:ZGRZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

The best practice for using CentOS with EC2 is to use the officially-supported AMIs, so I’m not sure I have control over that. At least one of the issues in that post referenced a fix, but I’m running the latest Docker build from their official Yum repository, so I assume that either that fix isn’t apparent in my build or I’m running into an unresolved issue.

Time to report a bug against that AMI, then.

The two issues linked to in this post were #9572 (filed in 2014 and not XFS specific) and #27358 which was acknowledged as not a Docker bug (and which led to the change to make it obvious in docker info that Supports d_type: false).

This is not a bug in Docker. You are running a configuration that does not work, and absent some changes to the kernel, cannot work. Your options are as previously described in this post.

2 Likes

I’ll reach out to my account manager at Amazon tomorrow. Thanks for the help.

I’ve already included solutions in my original post, anything stopped you from doing that?

Three little letters: A. W. S.

1 Like