Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container starts before database is ready #64

Open
askiiart opened this issue Nov 15, 2023 · 3 comments
Open

Container starts before database is ready #64

askiiart opened this issue Nov 15, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@askiiart
Copy link

Have you checked the roadmap on the website, and existing issues, before opening a dupllcate issue?
Yes

Describe the bug
An SQL error is shown when TMDB_API_KEY is not provided.

To Reproduce
Steps to reproduce the behavior:

  1. Create new bitmagnet instance without an API key
  2. Go to the web UI.

Expected behavior
It should have a more descriptive error message that says that TMDB_API_KEY is missing.

General (please complete the following information):

  • Bitmagnet version: 0.1.1
  • OS and version: Docker on Debian 12.

Additional context

Screenshot:

Snapshot_2023-11-15_13-39-44

@askiiart askiiart added the bug Something isn't working label Nov 15, 2023
@askiiart askiiart changed the title Short description of bug Missing TMDB_API_KEY throws SQL error that doesn't describe the issue Nov 15, 2023
@mgdigital
Copy link
Collaborator

Hi, this error isn't related to the TMDB API key - looks like an issue with your backend DB connection, either the migrations didn't run, a table got dropped or there's a connection issue. Can you see any tables or data in your DB, especially the torrent_contents table?

@Send8213
Copy link

Describe the bug

I can reproduce a similar error when starting it up with a near stock compose file with no existing data. When it happens, the bitmagnet database does not exist in postgres when checked directly (e.g. \c bitmagnet; \d), even after waiting 5+ minutes. Restarting with compose down and up a few times does seem to fix it for me.

Could the bitmagnet service be trying to access and use the database before it has been fully setup?

To Reproduce

  1. Up the compose file with no existing data
  2. Check that bitmagnet database is not created
  3. Restart using docker compose down and up
  4. Not all tables are present still
  5. Restart again
  6. Everything seems to be working and there are no database errors in the logs

Expected behavior
The database should be set up and ready to use upon first start, not needing repeated restarts.

General (please complete the following information):

  • Bitmagnet version: 0.1.1
  • OS and version: podman and podman-compose on Fedora 39.
  • Browser and version (if issue is with WebUI): Firefox 119

Additional context
Tested with both the build: and image: versions.

Changes to docker-compose.yml from docker-compose.dev.yml:
bind mounts for all three containers changed to named volumes.

Selection of logs from the database via (I seem to be able to recreate the pattern consistently):
docker logs bitmagnet-postgres

First startup:
LOG: database system is ready to accept connections
ERROR: relation "torrents" does not exist at character 177

Second startup:
LOG: database system is ready to accept connections
ERROR: relation "goose_db_version" does not exist at character 36

Third startup:
LOG: database system is ready to accept connections
(no errors)

@mgdigital mgdigital changed the title Missing TMDB_API_KEY throws SQL error that doesn't describe the issue Container starts before database is ready Nov 16, 2023
@mgdigital
Copy link
Collaborator

Hi, looks like this is due to the Postgres health check: pg_isready reports that the DB server is ready to accept connections, but doesn't guarantee that the database defined in POSTGRES_DB has been created yet.

There's a possible workaround here: https://stackoverflow.com/questions/14549270/check-if-database-exists-in-postgresql-using-shell/16783253#16783253 but it seems convoluted - there must be a better way. Perhaps it should be the Bitmagnet container's job to attempt DB creation if it doesn't exist and we'd remove the POSTGRES_DB env var, but I'm not sure I like that either. The POSTGRES_DB env var on that Docker image has surely been provided for this purpose but then they've provided no simple way to ensure a smooth startup...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants