1

I am fairly new to docker and I was changing some settings in postgres.conf inside my timescaledb container running on WSL2. I promptly restarted the container to apply my changes and it appears that I have added an unnecessary comma and the container will not start. Below is the log that reflects this.

2021-07-20 17:02:59.933 GMT [1] LOG:  syntax error in file "/var/lib/postgresql/data/postgresql.conf" line 59, near token ","
2021-07-20 17:02:59.933 GMT [1] FATAL:  configuration file "/var/lib/postgresql/data/postgresql.conf" contains errors

PostgreSQL Database directory appears to contain a database; Skipping initialization

2021-07-20 17:49:58.494 GMT [1] LOG:  syntax error in file "/var/lib/postgresql/data/postgresql.conf" line 59, near token ","
2021-07-20 17:49:58.494 GMT [1] FATAL:  configuration file "/var/lib/postgresql/data/postgresql.conf" contains errors

Now, the container always fails to start upon restart. I have no backups of this container and it contains about 100gb of data. The way I see it right now, there are three options:

  1. Is there is any way that I could start this container without postgres/timescaledb running so that way I can go in an fix the comma. This would be the easiest option.
  2. Is this some place where I would have to go into the internal file system on the host machine to fix the comma?
  3. Restarting the container from the base image (I really do not want to do this)

Any help would be greatly appreciated. Below are some details about my environment:

Client:
 Cloud integration: 1.0.14
 Version:           20.10.6
 API version:       1.41
 Go version:        go1.16.3
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.6
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  OS/Arch:          linux/amd64
  Experimental:     false

REPOSITORY              TAG         
timescale/timescaledb   2.3.1-pg13
Zach
  • 35
  • 1
  • 7

1 Answers1

1

Like most database images, the timescaledb image does not place your data in the container root filesystem -- it creates a volume for the data instead. By default this is an "anonymous" volume -- it has no name, and will be deleted when your delete your container.

To access the data from your timescaledb container, you first need to determine the volume id. You can get that from the output of docker container inspect:

$ docker inspect timescale --format="{{ range .Mounts }}{{.Name}}{{end}}"
bee238efb681cd88c20ddedc46ca4a55a0b6b598f5c137945e8d6714fce99d4b

Here, I can see that my container named timescale was attached to the volume bee238efb681cd88c20ddedc46ca4a55a0b6b598f5c137945e8d6714fce99d4b (you would replace timescale in the above command with the name or id of your failed container). I can start up a new container using the same volume so that I can edit the configuration file(s):

$ docker run -v bee238efb681cd88c20ddedc46ca4a55a0b6b598f5c137945e8d6714fce99d4b:data --rm -it alpine sh
/ # cd /data
/data # ls
PG_VERSION            pg_commit_ts          pg_ident.conf         pg_notify             pg_snapshots          pg_subtrans           pg_wal                postgresql.conf
base                  pg_dynshmem           pg_logical            pg_replslot           pg_stat               pg_tblspc             pg_xact               postmaster.opts
global                pg_hba.conf           pg_multixact          pg_serial             pg_stat_tmp           pg_twophase           postgresql.auto.conf

The volume is mounted on /data, and I'm free to edit files there. Once you've made the necessary changes, you can exit this temporary container and then restart your failed container.

When running any sort of service for which you want your data to persist longer than the lifetime of the container, you should arrange to store your data in a named volume, which are never removed automatically.

You create a named volume by passing a name as the first argument to -v, for example:

docker run -v myimportantdata:/var/lib/postgresql/data ...

This creates a named volume named myimportantdata if it doesn't already exists, and mounts it in the container at the given path.

You should also, of course, arrange to automatically back up any data that you care about.

larsks
  • 277,717
  • 41
  • 399
  • 399
  • Hello, thank you for your response. When I created the bugged container, I specified a volume `myvolume` with the -v flag in 'docker run...' . Would this change up the process of finding where it is at all? I tried following along to your response without any luck. `docker run -v :data --rm -it alpine sh docker: Error response from daemon: invalid volume specification: ':data': invalid mount config for type "volume": invalid mount path: 'data' mount path must be absolute.` – Zach Jul 20 '21 at 19:11
  • Also, 'docker run -v myvolume:data --rm -it alpine sh' results in the same error. However, 'docker run -v myvolume/data --rm -it alpine sh' shows that there is nothing in the data folder – Zach Jul 20 '21 at 19:18
  • You have problems with your cli syntax in both of your comments. You're missing the initial `/` on `/data`: `-v :/data` (and in your second example, you seem to have lost the necessary `:` that separates the volume name from the mount path). – larsks Jul 20 '21 at 19:34