Starting the container errors on old lock file.

[mauvm]

When I start the container (with Vagrant) it exists wit an error code (Exited (1)). This is what the log looks like:

POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Initializing PostgreSQL at /data
Starting PostgreSQL...
Creating the superuser: postgres
2014-05-08 10:12:25 UTC FATAL:  could not remove old lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Operation not permitted
2014-05-08 10:12:25 UTC HINT:  The file seems accidentally left over, but it could not be removed. Please remove the file by hand and try again.

Any idea what might cause this/how to fix this?

[Painted-Fox]

I believe I fixed this with the latest changes. Could you please verify?

[mauvm]

It sort of works again.. The lockfile error is gone, but now I get:

*** Running /etc/rc.local...
*** Booting runit daemon...
*** Runit started as PID 7
POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Starting PostgreSQL...
Creating the superuser: postgres
Unable to create the superuser.
Retrying in 3 seconds...
POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Starting PostgreSQL...
Creating the superuser: postgres
Unable to create the superuser.
Retrying in 3 seconds...
POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Starting PostgreSQL...
Creating the superuser: postgres
Unable to create the superuser.
Retrying in 3 seconds...

... (x100)

POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Starting PostgreSQL...
Creating the superuser: postgres
Unable to create the superuser.
Retrying in 3 seconds...
Unable to create the superuser.
Retrying in 3 seconds...
Unable to create the superuser.
Retrying in 3 seconds...
POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Starting PostgreSQL...
Creating the superuser: postgres
Unable to create the superuser.
Retrying in 3 seconds...
Unable to create the superuser.
Retrying in 3 seconds...
Unable to create the superuser.
Retrying in 3 seconds...
Unable to create the superuser.
Retrying in 3 seconds...
POSTGRES_USER=postgres
POSTGRES_PASS=somepassword
POSTGRES_DATA_DIR=/data
POSTGRES_DATABASE=UNWDMI
Starting PostgreSQL...
Creating the superuser: postgres
Unable to create the superuser.
Retrying in 3 seconds...

...

Looks like an infinite loop..

[Painted-Fox]

Curious. I haven't been able to reproduce this myself yet.

Can you tell me the exact command you are using to start your container? Also, are you using the image from the docker repository or are you building it with this Dockerfile?

I've not run Vagrant before... could you possibly point me to some resource on how to setup Docker inside Vagrant so I can reproduce your setup entirely?

[jirikolarik]

Hi, I have the same problem. You can setup vagrant with only few steps

1. vagrant init
2. edit your Vagrant file

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "phusion/ubuntu-14.04-amd64"

  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  # config.vm.box_url = "http://domain.com/path/to/above.box"

  config.vm.provision "docker", images: ["paintedfox/postgresql"] do |d|    
    d.run "paintedfox/postgresql", args: "--name=postgresql -v /vagrant/path/to/your/folder:/var/lib/postgresql -p 5432:5432 ", daemonize: true
  end

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  config.vm.network "forwarded_port", guest: 5432, host: 5432
end

1. run vagrant by vagrant up

[Painted-Fox]

@jirikolarik Thank you very much! I believe I'm able to reproduce the issue now. I'm taking a look into it.

[Painted-Fox]

Whew. I think this is finally fixed. Could you please verify?

[mauvm]

Hmm.. It hangs on:

==> default: Running provisioner: docker...
    default: Installing Docker (latest) onto machine...
    default: Configuring Docker to autostart containers...
==> default: Starting Docker containers...
==> default: -- Container: postgresql

And vagrant ssh (in another tab) gives me:

An action 'ssh' was attempted on the machine 'default',
but another process is already executing an action on the machine.
Vagrant locks each machine for access by only one process at a time.
Please wait until the other Vagrant process finishes modifying this
machine, then try again.

If you believe this message is in error, please check the process
listing for any "ruby" or "vagrant" processes and kill them. Then
try again.

At first I thought it was pulling the image, but my Activity Monitor shows no increase in Received Bytes for VBoxHeadless.

[Painted-Fox]

I believe I've found a piece of the puzzle.

As part of the example Vagrantfile, if I leave out the -v /vagrant/path/to/your/folder:/var/lib/postgresql portion of the argument to start the container, the container does not go into a loop and appears to start correctly.

[TalkingQuickly]

@Painted-Fox could you share what the fix was for the original could not remove old lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Operation not permitted error? Running into this on another Postgres image (the example one from the Docker documentation) and can't for the life of me work out what's causing it.

[Painted-Fox]

I'm trying to remember. I suspect it has something to do with this commit: 0996a11. The phusion/baseimage expects to be initialized with /sbin/my_init. I'm not entirely sure that's what fixed the original issue though.