Switch from dynamic to static compose = intermittent postgres authentication failures?

Tiny Tiny RSS Support
1
  • [ ] I’m using stock docker compose setup, unmodified.
  • [X] I’m using docker compose setup, with modifications (modified .yml files, third party plugins/themes, etc.) - if so, describe your modifications in your post. Before reporting, see if your issue can be reproduced on the unmodified setup.
  • [ ] I’m not using docker on my primary instance, but my issue can be reproduced on the aforementioned docker setup and/or official demo.

I have run docker-compose dynamic version for a long time, and recently tried to change to static image version. I switched the branch to static-dockerhub as instructed here, retaining the same docker-compose.override.yml and .env file. However, it did not go well.

The app container log has errors like:
app_1 | psql: error: FATAL: password authentication failed for user “postgres”
app_1 | db:5432 - accepting connections
…
app_1 | 

Exception while creating PDO object:SQLSTATE[08006] [7] FATAL:  password authentication failed for user “postgres”
db:5432 - accepting connections

The updater container log has errors like:
PHP Fatal error: Uncaught PDOException: SQLSTATE[08006] [7] FATAL: password authentication failed for user "postgres" in /var/www/html/tt-rss/vendor/j4mie/idiorm/idiorm.php:328

Instead of displaying the web UI, it displays either 502 Bad Gateway or an error message:
Exception while creating PDO object:SQLSTATE[08006] [7] FATAL: password authentication failed for user "postgres"
One time it actually loaded the login page, but when I submitted credentials it returned the above error.

I switched back to the master branch, but the errors continued.

Thinking the db account password might have gotten screwed up, I reset it to the default “password” with the \password command, after launching psql as the postgres user. That’s the password set in .env file for TTRSS_DB_PASS. I can confirm the account/pw works by connecting via psql from the app and updater containers - but it only works sometimes. Other times it gives me:
psql: error: FATAL: password authentication failed for user "postgres"

  • Tiny Tiny RSS version (including git commit id):
    • latest commit = 2654b3c6be408113ede52180ae283afa72da5f3c
  • Platform (i.e. Linux distro, Docker, PHP, PostgreSQL, etc) versions:
    • Unraid 6.9.2 (slackware linux)
    • Docker version 20.10.5, build 55c4c88
    • PHP 8.0.13 (as provided by docker-compose file)
    • PostgreSQL 12.10 (as provided by docker-compose file)
  • I migrated my data from docker volumes to host folders
  • I’m using a separate nginx reverse proxy (swag)
  • These plugins are enabled: api_feedreader, data_migration, feedprefs, mercury_fulltext, options_per_feed, unread_oldest_first, api_newsplus, feediron, fever, markread_plus, nginx_xaccel, ui_gravatar

Any suggestions for diagnosing the problem? I’ve searched the forums and hit on a few keywords, but didn’t see any answers.

2

Concurrent containers (static and dynamic) on the same docker network and/or the same docker volumes interfering with each other?

3

Good question, but there’s no concurrency. I down the stack before switching branches and bringing up the new stack.

4

i’m not stopping anyone from posting here but in all honesty i’m not sure what drives people to come here with their docker-related problems which are not specific to tt-rss.

i.e.

inter-container traffic doesn’t work because fox screwed up service names in the stock compose file

= tt-rss packaging issue, valid.

error 500 on startup because of syntax error in whatever.php

= tt-rss issue, valid.

someone did god knows what with his docker setup, things don’t work no more

= not tt-rss related, invalid.

i’m using synology, and…

= no

just, you know, outlining the boundaries here. not even mentioning that a lot of issues would be impossible to diagnose remotely, not that i would even bother because fixing and maintaining infrastructure is, well, work.

try compose logs.

5

Predictably it seems one of my modifications was the issue. While I’ve never had a problem specifying an external docker network as the default, as soon as I remove it from compose, all the authentication failures go away. I’m able to maintain communication with the swag proxy by adding an unraid “post argument” to the swag container that connects it to the ttrss-docker_default network.