mirego / accent

The first developer-oriented translation tool. True asynchronous flow between translators and your team.
https://www.accent.reviews
BSD 3-Clause "New" or "Revised" License
1.3k stars 97 forks source link

DB Connection Failed #449

Open FuckingToasters opened 2 months ago

FuckingToasters commented 2 months ago

Hello, yesterday accent worked fine, i were able to login with github, add translations etc.

Today i noticed, that nothing would load, so i logged out, once i tried to log back in, i got an json error saying something around the lines of "something went wrong, someone has been notified"

IK then went ahead and checked the docker logs which did show me following:


 ✘ ⚡ root@cyan-mosquito-96238  ~  docker logs accent
Running migrations for accent…
08:15:57.260 [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 :accent, Accent.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 5953ms. 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.0) lib/ecto/adapters/sql.ex:1078: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.17.2) lib/enum.ex:1703: Enum."-map/2-lists^map/1-1-"/2
    (ecto_sql 3.12.0) lib/ecto/adapters/sql.ex:1185: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.12.0) lib/ecto/migrator.ex:779: Ecto.Migrator.verbose_schema_migration/3
    (ecto_sql 3.12.0) lib/ecto/migrator.ex:563: Ecto.Migrator.lock_for_migrations/4
    (ecto_sql 3.12.0) lib/ecto/migrator.ex:432: Ecto.Migrator.run/4
    (ecto_sql 3.12.0) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
    nofile:1: (file)

I then checked the postgres container logs which did show more info as to what the error is:

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-09-10 08:16:34.892 UTC [1] FATAL:  could not write lock file "postmaster.pid": No space left on device

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-09-10 08:17:01.120 UTC [1] FATAL:  could not write lock file "postmaster.pid": No space left on device

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-09-10 08:17:52.725 UTC [1] FATAL:  could not write lock file "postmaster.pid": No space left on device

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-09-10 08:18:53.255 UTC [1] FATAL:  could not write lock file "postmaster.pid": No space left on device

After that, i ran the command docker system prune which freed around 10GB. The deletion of the 10Gb seem to have soled the issue, I think it would be nice to also show that the disk may be full in the accent log output.