Can not get teslamate working

[kerbero81]

Hello, I am trying to set up teslamate for my vehicle. This is the first time I use docker so I am pretty lost... I followed a tutorial, that made me set the following environment:

• VM on Oracle Cloud, wich is working fine.
• Zerotier to set a VPN connection, wich is working fine as well, because I can make ping between both machines.

For the instalation of teslamate

• At first I followed the instructions on https://docs.teslamate.org/docs/installation/docker, wich I could not make work, nor grafana nor teslamate answered on their, my_ip:port.
• Then I followed the advanced installation, wich worked only for grafana, but teslamate keept not working.
  I have googled a lot but I have not been able to find a solution. The only thing that I can say is that, on teslamate logs, I can see an endles list of:

waiting for postgres at database:5432
waiting for postgres at database:5432
waiting for postgres at database:5432 ...

The log file does not have anything else, and keeps being updated every two seconds or so. So I think it is clear that something here is not working fine.

I have entered on the postgress database directly, and it seems its working:
psql -h 172.20X.X -p 5432 -U XXXX

teslamate=# SELECT version();
version

PostgreSQL 14.7 (Debian 14.7-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
(1 row)

Does anybody have an idea how to make it work?

[DrMichael]

Well, teslamate cannot connect to the database at 5432. You need to check that.

[kerbero81]

Hi! Thanks for your answer, as I said, I am absolutely new on docker, so, please, could you tell me how to check it?

Thank you!

[DrMichael]

For a start the docker-compose.yml would be helpful.

[kerbero81]

Hello!
Right now I have copied and pasted the docker-compose.yml from https://docs.teslamate.org/docs/guides/traefik with the .env as advised there. The only points I have in doubt are the FQDN wich I do not have any so I think I could delete them as I have read that they are optional.
Other points I do that I am not sure I am doing rigth are the commands to update the system when I introduce changes on the .yml file: I use sudo docker-compose pull and then: sudo docker-compose up -d --remove-orphans

[DrMichael]

What gives docker-compose ps and docker ps?

[DrMichael]

Hard to read, but all services up...

What with docker-compose logs teslamate and docker-compose logs database?

[kerbero81]

Yes, sorry its better to read it on the ssh display.

sudo docker logs teslamate_teslamate_1, as I said is:

waiting for postgres at database:5432
waiting for postgres at database:5432
waiting for postgres at database:5432
waiting for postgres at database:5432
waiting for postgres at database:5432
waiting for postgres at database:5432

That keep adding one new line every second

For sudo docker logs teslamate_database_1:

PostgreSQL Database directory appears to contain a database; Skipping initialization

2023-04-09 13:29:36.606 UTC [1] LOG: starting PostgreSQL 14.7 (Debian 14.7-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-04-09 13:29:36.606 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2023-04-09 13:29:36.606 UTC [1] LOG: listening on IPv6 address "::", port 5432
2023-04-09 13:29:36.615 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-04-09 13:29:36.622 UTC [26] LOG: database system was shut down at 2023-04-09 13:29:27 UTC
2023-04-09 13:29:36.643 UTC [1] LOG: database system is ready to accept connections

As I said on my first post, I can access grafana via my-ip:3000 and, once introduced user/pwd, I can see Teslamate data source and, if I try, "Save and test" and get: Database Connection OK

[DrMichael]

Sorry out of ideas. No idea, why grafana can connect to the database and teslamate cannot...

[sedetweiler]

I am having the exact same issue. Grafana can connect but teslamate cannot. It is all running, but postgress is waiting

[kerbero81]

Sorry to read that. I ended up creating a new VM and setting up the new environment from scratch. I do not know what happened but, clearly, had something to do with the environment. I can tell you, logs from the containers are useless for this problem.

[tills13]

Just ran into this myself after changing my network. The way I solved it was to destroy the teslamate docker network

docker network rm teslamate_default

and then restart the app

docker compose up --force-recreate

[sedetweiler]

I started over and removed all of the old databases, folders, and connections. I am using version 16 for Postgres, and sure enough, I am back to the "waiting for Postgres at database:5432" on my Synology. The database shows as "system is ready for accept connections" My yaml is a copy of the latest one with the passwords and keys changed as expected. I keep hitting the same wall every time I attempt this.
teslamate docker config.txt Help, please?

[eliluong]

I would try to expose the postgres ports next

[sedetweiler]

How would you do that? I have the network ports at the router open, but not sure how docker works that way. Am I the only one with the issue?

…

On Thu, Nov 28, 2024, 12:45 PM eliluong ***@***.***> wrote: I would try to expose the postgres ports next — Reply to this email directly, view it on GitHub <#3180 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB72USOEF6RPZ7NJLZRSM432C5QFDAVCNFSM6AAAAABSVMZQQKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBQHE2DQOA> . You are receiving this because you commented.Message ID: ***@***.*** com>

[eliluong]

It would involve adding a ports section in the database service for the port 5432. This opens up the database so you can access it from outside Docker. In retrospect this may not fix the issue, but I'm not familiar with how synology manages docker stuff, and just thinking of things to try.

I would also run docker ps, get the container id of the teslamate service, then run docker inspect CONTAINER_ID --format '{{ json .NetworkSettings.Networks }}' to get the Docker network name that teslamate is on. For me it is teslamate_default. Then run docker network inspect NETWORK_NAME to see if all four services (teslamate/grafana/mqtt/postgres) are on the same network. You look at the Containers section and there should be four of them. Otherwise if they are not, then the services will not be able to communicate with each other.

CONTAINER ID   IMAGE                           COMMAND                  CREATED         STATUS                PORTS                                                                                            NAMES
f101dae7ea17   teslamate/teslamate:1.28.3      "tini -- /bin/sh /en…"   4 months ago    Up 6 days             0.0.0.0:4000->4000/tcp, :::4000->4000/tcp                                                        teslamate-teslamate-1

~/Downloads/teslamate$ docker inspect 3b81051c4d1a --format '{{ json .NetworkSettings.Networks }}'
{"teslamate_default": ....}

Additionally, you can run docker exec -it teslamate-teslamate-1 bash (or use the container id instead of teslamate-teslamate-1). This gets you inside the container of teslamate service. Then run nc -zv database 5432. This will test to see if the teslamate container can reach the database container on the port for postgres. Because postgres is running and on that port, it should say something like Connection to database (172.21.0.5) 5432 port [tcp/*] succeeded!. If you run nc -zv grafana 3000 it should show something similar.

Another thing to try is add this depends_on section to the teslamate service. This would make sure the database is up and running before starting teslamate. I don't know if Teslamate will keep polling to check for the database or just try it once and stop.

services:
  teslamate:
    image: teslamate/teslamate:latest
    ///
    ports:
      - 4000:4000
    depends_on:
      - database
    ///

[sedetweiler]

Happy Thanksgiving, and thank you for this answer! I will work my way though this tomorrow, and appreciate you taking the time to put together such a great series of things to try. Cheers!

[sedetweiler]

okay, all in the same network but with the same error. Has anyone been able to get this working on a synology?

2024-11-29 15:14:00.123 [error] Could not create schema migrations table. This error usually happens due to the following:
  * The database does not exist
  * The "schema_migrations" table, which Ecto uses for managing
    migrations, was defined by another library
  * There is a deadlock while migrating (such as using concurrent
    indexes with a migration_lock)
To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
To address the second, you can run "mix ecto.drop" followed by
"mix ecto.create", both for the desired MIX_ENV. Alternatively you may
configure Ecto to use another table and/or repository for managing
migrations:
    config :teslamate, TeslaMate.Repo,
      migration_source: "some_other_table_for_schema_migrations",
      migration_repo: AnotherRepoForSchemaMigrations
The full error report is shown below.
** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2969ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
  1. Ensuring your database is available and that you can connect to it
  2. Tracking down slow queries and making sure they are running fast enough
  3. Increasing the pool_size (although this increases resource consumption)
  4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
See DBConnection.start_link/2 for more information
    (ecto_sql 3.12.1) lib/ecto/adapters/sql.ex:1096: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.17.3) lib/enum.ex:1703: Enum."-map/2-lists^map/1-1-"/2
    (ecto_sql 3.12.1) lib/ecto/adapters/sql.ex:1203: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.12.1) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
    (ecto_sql 3.12.1) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
    (ecto_sql 3.12.1) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
    (ecto_sql 3.12.1) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
    nofile:1: (file)
waiting for postgres at database:5432

[sedetweiler]

Here is the log from postgres:

 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 dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
initdb: hint: 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.
Success. You can now start the database server using:
    pg_ctl -D /var/lib/postgresql/data -l logfile start
waiting for server to start....2024-11-29 15:13:45.807 UTC [48] LOG:  starting PostgreSQL 16.6 (Debian 16.6-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-11-29 15:13:46.131 UTC [48] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
.2024-11-29 15:13:46.784 UTC [51] LOG:  database system was shut down at 2024-11-29 15:13:44 UTC
2024-11-29 15:13:46.885 UTC [48] LOG:  database system is ready to accept connections
 done
server started
CREATE DATABASE
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
waiting for server to shut down...2024-11-29 15:13:49.754 UTC [48] LOG:  received fast shutdown request
.2024-11-29 15:13:50.123 UTC [48] LOG:  aborting any active transactions
2024-11-29 15:13:50.126 UTC [48] LOG:  background worker "logical replication launcher" (PID 54) exited with exit code 1
2024-11-29 15:13:50.128 UTC [49] LOG:  shutting down
2024-11-29 15:13:50.546 UTC [49] LOG:  checkpoint starting: shutdown immediate
...2024-11-29 15:13:53.490 UTC [49] LOG:  checkpoint complete: wrote 922 buffers (5.6%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.303 s, sync=1.527 s, total=3.363 s; sync files=301, longest=0.480 s, average=0.006 s; distance=4255 kB, estimate=4255 kB; lsn=0/1912108, redo lsn=0/1912108
2024-11-29 15:13:53.497 UTC [48] LOG:  database system is shut down
 done
server stopped
PostgreSQL init process complete; ready for start up.
2024-11-29 15:13:54.202 UTC [1] LOG:  starting PostgreSQL 16.6 (Debian 16.6-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-11-29 15:13:54.203 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-11-29 15:13:54.203 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2024-11-29 15:13:54.604 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-11-29 15:13:55.049 UTC [64] LOG:  database system was shut down at 2024-11-29 15:13:53 UTC
2024-11-29 15:13:55.220 UTC [1] LOG:  database system is ready to accept connections
2024-11-29 15:18:55.148 UTC [62] LOG:  checkpoint starting: time
2024-11-29 15:18:57.283 UTC [62] LOG:  checkpoint complete: wrote 4 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.101 s, sync=0.290 s, total=2.135 s; sync files=3, longest=0.191 s, average=0.097 s; distance=0 kB, estimate=0 kB; lsn=0/19121F0, redo lsn=0/19121B8

[eliluong]

You can try changing teslamate-db:/var/lib/postgresql/data to something like ./teslamate-db:/var/lib/postgresql/data.

So instead of Docker putting the volumes somewhere, it will go into the local directory. Plus it will give you a fresh blank database to work with. Then do docker compose down before starting it all up again.

[Charlsburg]

The solution to this is to fix your TeslaMate docker config -
The instructions are VERY unclear so this is an easy mistake to make, but the value of "DATABASE_HOST" needs to point directly at your postgres db. So putting "teslamate" or "database" wont help, try the actual IP postgres is running from (i.e. 192.168.150.10)

[dobunzli]

Hello, I have the same problem and opened a bug report here #4458 (comment)

[dobunzli]

Just to let you know, I was able to install. See bug post. I still have to investigate which port forwarding exactly I need so that it works completely but install was successfull. Hope this helps !

[dobunzli]

Regarding port forwarding: you also have to set an allow rule for the Docker bridge network into the Synology NAS firewall to resolve the DNS and connexions issues. Everything is working well now !

[sedetweiler]

Can you give me more details on this, please? I am not sure I fully understand what I need to do.

…

On Wed, Jan 1, 2025 at 5:19 AM dobunzli ***@***.***> wrote: I found finally the problem: you have to set an allow rule for the Docker bridge network into the Synology NAS firewall to resolve the DNS and connexions issues. Everything is working now ! — Reply to this email directly, view it on GitHub <#3180 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB72USOJOA64SN3KEEXR7CT2IPFNVAVCNFSM6AAAAABSVMZQQKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZQHE3DOMQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[dobunzli]

See for instance this video https://youtu.be/-my0ilNnxR4?si=NZGIPqtMF139ARyx

[hmouridsen]

Sorry to interrupt- I have the same problem here - running PostgreSQL14.17.

I do have a backup, but I'm unsure how to delete the database? What command to I need to run?

Thanks

[brianmay]

Try to make sure that the backup is valid before doing any deletion. Otherwise you could lose all your data.

I am in the process of revising the instructions - see #4726

[hmouridsen]

Ohh I saw your post a little too late. I'm currently doing the old way, and is in the middle of the data import now - hopefully my data is fine :)