Installation failing on CentOS 7.3

support
1

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
2

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

3

Does Discourse on CentOS 7.3 help you at all?

1 Like
4

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.

5

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
6

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.

7

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
8

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

9

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

10

Three little letters: A. W. S.

1 Like