0

I haven't run this particular build in a month or so, and I recently updated from drone version 0.5 to 0.7.3. I've hit an issue where a a build with a postgres service never completes. According to the logs, it should be accepting connections, but it never moves past the the step of starting up the service.

Example that will Stall out

.drone.yml

pipeline:
  Run Something:
    image: busybox
    commands:
      - echo 'hello'

services:
  postgres:
    image: postgres
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=pgpass
    ports:
      - '15432:5432'

Log Output

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgresql/data -l logfile start


WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....LOG:  database system was shut down at 2017-08-17 00:06:37 UTC
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
 done
server started
ALTER ROLE


/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*

LOG:  received fast shutdown request
LOG:  aborting any active transactions
LOG:  autovacuum launcher shutting down
waiting for server to shut down....LOG:  shutting down
LOG:  database system is shut down
 done
server stopped

PostgreSQL init process complete; ready for start up.

LOG:  database system was shut down at 2017-08-17 00:06:38 UTC
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

Notes

Everything just stays here, and the build never completes. If I remove the ports and environment variables, I can get it to run. I did that in a sandbox that doesn't require configuration to run properly... Of course, in practice, I do need to adjust ports and passwords to make the build function properly.

I haven't changed anything but the version of drone in the last month or so. I'm stumped.

Things I've Tried

  • Changing removing one ENV var at a time
  • Different versions of postgres
  • Not defining the port mapping
  • Using detach: true rather than a service

Thank for your time!

counterbeing
  • 2,721
  • 2
  • 27
  • 47
  • Try going to 0.6 and see if that helps? May be your upgrade is an issue? Try mounting a new composition without previous data – Tarun Lalwani Aug 17 '17 at 09:35
  • That's a good idea. I know some migrations ran on the previous drone updates, hopefully that doesn't mess anything up. – counterbeing Aug 17 '17 at 18:18
  • 1
    I can confirm you should remove the port mapping – Brad Rydzewski Aug 24 '17 at 04:46
  • I am unable to repeat any issues with the example yaml. There are no known issues with services in 0.7.3 (so downgrading to 0.6 would not make a difference). I would recommend looking at the following documentation as a starting point http://docs.drone.io/postgres-example/#working-example – Brad Rydzewski Aug 24 '17 at 05:07

1 Answers1

0

After looking this over for a while, I couldn't locate the source of the problem. I decided to spin up an all new instance of drone that hadn't been upgraded, and reconfigure it. This appears to be working now. My only guess is that there was some kind of corruption.

At least running with docker spinning up a new instance to test was pretty easy.

counterbeing
  • 2,721
  • 2
  • 27
  • 47