Launcher rebuild breaks because the database system is starting up

When doing a ./launcher rebuild it breaks with

RuntimeError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 108 exit 2>

Looks like the PostgeSQL server is not available because it is starting up.

Complete launcher log is here:

http://pastebin.com/3x9TsZA5

Any ideas how to fix or debug this?

(I use the standalone template.)

If you are using different containers for db and web, maybe ensure that the db container is started first and the startup of the web container is delayed to account for that?

I do not use different containers but the standalone one. So DB is running within the app container.

Did you call the instance “discourse”? the default from our install guide is “app”.

I think this might be a failed install, so I would start over from scratch using our official guide and following it exactly, step by step.

What OS are you installing on? The recommended Ubuntu 14.04 x64 LTS?

Yes I call it “discourse” because it is running together with many other containers. Having it named just “app” feels like calling my girl friend something like - “girl friend” :wink: Install went well and it runs well too. Just the rebuild does fail. Should this be because I do not call it “app”?

I’m using CentOS 7 on the host because the host itself is an OpenVZ container. My tests with Ubuntu did not worked well so I went the CentOS road because that’s what OpenVZ supports best. So far no problems using this setup.

1 Like

OpenVZ has been a disaster for Docker.

What does docker --info and docker --version say?

Version should be 1.6.1+ and docker info should say you are using AUFS. If you are using devicemapper that is broken and unsupported.

# docker --version
Docker version 1.6.0, build 8aae715/1.6.0

# docker info
...
Storage Driver: vfs

Guess I need to reconsider my OS decisions…

Hmm don’t know about vfs. But I suspect it’s broken, like devicemapper. Any ideas @sam?

// Slice of drivers that should be used in an order
 priority = []string{
 "aufs",
 "btrfs",
 "devicemapper",
 "vfs",
 "overlayfs",

Never used vfs, I don’t know what the status of it is.

Digging into this a little more, the only viable practical options are

  • AUFS
  • overlayfs

Unfortunately, AUFS is not part of the kernel and will never be, overlayfs looks like it will make it into the kernel, but could be bleeding edge at the moment.

@sam is adding better protection for this in the bootstrap step – we really can’t proceed if the filesystem is not one that is known to be compatible with Docker. Too many support issues…

Done:

https://github.com/discourse/discourse_docker/commit/48f22d14f39496c8df446cbc65ee04b258c5a1a0

We used to allow people to skip our warning, that was a mistake.

2 Likes