Вот дополнительная информация. В stderr gunicorn я вижу:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.7/lib/active_record/connection_adapters/postgresql_adapter.rb:87:in `rescue in new_client': connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory (ActiveRecord::ConnectionNotEstablished)
Is the server running locally and accepting connections on that socket?
В логе PG я вижу:
2023-08-21 19:24:00.721 UTC [1681] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-08-21 19:24:00.728 UTC [1681] LOG: could not open configuration file "/etc/postgresql/13/main/pg_hba.conf": Permission denied
2023-08-21 19:24:00.728 UTC [1681] FATAL: could not load pg_hba.conf
2023-08-21 19:24:00.741 UTC [1681] LOG: database system is shut down
Далее:
# ls -l /etc/postgresql/13/main/pg_hba.conf
-rw-r----- 1 root root 4846 Aug 21 19:05 /etc/postgresql/13/main/pg_hba.conf
Под каким пользователем работает postgres внутри контейнера? С учётом вышеуказанных прав доступа, это должен быть root или кто-то из группы root.
Хорошо, я выполнил chmod o+r /etc/postgresql/13/main/pg_hba.conf, и теперь контейнер снова запущен.
Это немного беспокоит — почему рекомендуемый метод установки не работает из коробки? Мой статус плагинов сейчас включает те, что перечислены выше, за исключением Data Explorer, который я отключил, так как он вызывал сбой в прошлый раз.
Перекрёстная ссылка на
где сообщается о подобных симптомах.
Обновление: Я изменил команду git в секции cmd файла app.yml, чтобы использовать sudo, как описано в связанном посте.
Я считаю этот сбой прерывистым. Из трёх попыток (после каждой я полностью очищал директорию shared) один раз удалось, а два раза — нет. При сбое ручное исправление трёх проблемных прав доступа и последующая перезапуск контейнера приводили к тому, что система, судя по всему, работала нормально. Было бы неплохо иметь улучшенное логирование и более эффективные автоматические тесты для обнаружения сбоев при запуске контейнера.