gvmd@gvmd FATAL: remaining connection slots are reserved for non-replication superuser connections #2038
Comments
|
The docker deployment works, when downgrading gvmd to 22.5.2 Update 22.5.2 does have the same issue |
|
This issue originated from https://forum.greenbone.net/t/sql-open-pqerrormessage-conn-fatal-remaining-connection-slots-are-reserved-for-non-replication-superuser-connections/15137 As far as I understand using gvmd 22.5.1 should work because it got introduced with #2028 |
|
I have encountered the issue with PostgreSQL connections after building and running Greenbone Community Edition 22.4 from the source code on Ubuntu 22.04 LTS under Windows Subsystem for Linux (WSL). During normal operation, I encountered the following errors: md manage:WARNING:2023-07-07 11h57.55 utc:16975: init_manage_open_db: sql_open failed
md manage:WARNING:2023-07-07 11h57.55 utc:16974: sql_open: PQconnectPoll failed
md manage:WARNING:2023-07-07 11h57.55 utc:16974: sql_open: PQerrorMessage (conn): connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: remaining connection slots are reserved for non-replication superuser connectionsAfter I saw this in the logs, the web interface stopped working and only three tabs remained. I ran md main:MESSAGE:2023-07-07 13h19.47 utc:5411: Greenbone Vulnerability Manager version 22.5.2 (DB revision 255)
md manage:MESSAGE:2023-07-07 13h19.47 utc:5411: No SCAP database found
md manage:WARNING:2023-07-07 13h19.49 UTC:5433: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage: INFO:2023-07-07 13h19.49 UTC:5433: update_scap: Updating data from feed
md manage: INFO:2023-07-07 13h19.49 UTC:5433: Updating CPEs
md manage: INFO:2023-07-07 13h22.20 UTC:5433: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2014.xml
md manage: INFO:2023-07-07 13h22.28 UTC:5433: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2002.xml
md manage: INFO:2023-07-07 13h22.35 UTC:5433: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2022.xml
md manage:WARNING:2023-07-07 13h23.58 utc:6217: sql_open: PQconnectPoll failed
md manage:WARNING:2023-07-07 13h23.58 utc:6217: sql_open: PQerrorMessage (conn): connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: remaining connection slots are reserved for non-replication superuser connectionsThen after several restarts, the progress moved forward and I already saw the following: md main:MESSAGE:2023-07-07 13h28.13 utc:6377: Greenbone Vulnerability Manager version 22.5.2 (DB revision 255)
md manage:MESSAGE:2023-07-07 13h28.13 utc:6377: No SCAP database found
md manage:WARNING:2023-07-07 13h28.15 UTC:6400: update_scap: No SCAP db present, rebuilding SCAP db from scratch
md manage: INFO:2023-07-07 13h28.16 UTC:6400: update_scap: Updating data from feed
md manage: INFO:2023-07-07 13h28.16 UTC:6400: Updating CPEs
md manage: INFO:2023-07-07 13h31.14 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2014.xml
md manage: INFO:2023-07-07 13h31.21 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2002.xml
md manage: INFO:2023-07-07 13h31.25 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2022.xml
md manage: INFO:2023-07-07 13h32.01 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2019.xml
md manage: INFO:2023-07-07 13h32.36 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2006.xml
md manage: INFO:2023-07-07 13h32.42 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2013.xml
md manage: INFO:2023-07-07 13h32.49 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2020.xml
md manage: INFO:2023-07-07 13h33.15 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2018.xml
md manage: INFO:2023-07-07 13h33.42 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2010.xml
md manage: INFO:2023-07-07 13h33.49 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2012.xml
md manage: INFO:2023-07-07 13h33.57 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2003.xml
md manage: INFO:2023-07-07 13h33.59 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2023.xml
md manage: INFO:2023-07-07 13h34.14 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2005.xml
md manage: INFO:2023-07-07 13h34.19 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2004.xml
md manage: INFO:2023-07-07 13h34.23 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2021.xml
md manage: INFO:2023-07-07 13h35.02 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2016.xml
md manage: INFO:2023-07-07 13h35.16 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2007.xml
md manage: INFO:2023-07-07 13h35.23 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2008.xml
md manage: INFO:2023-07-07 13h35.34 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2017.xml
md manage: INFO:2023-07-07 13h35.57 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2011.xml
md manage: INFO:2023-07-07 13h36.08 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2009.xml
md manage: INFO:2023-07-07 13h36.20 UTC:6400: Updating /var/lib/gvm/scap-data/nvdcve-2.0-2015.xml
md manage: INFO:2023-07-07 13h36.32 UTC:6400: Updating CVSS scores and CVE counts for CPEs
md manage: INFO:2023-07-07 13h39.12 UTC:6400: Updating placeholder CPEs
md manage: INFO:2023-07-07 13h39.43 UTC:6400: Updating Max CVSS for DFN-CERT
md manage: INFO:2023-07-07 13h39.49 UTC:6400: Updating DFN-CERT CVSS max succeeded.
md manage: INFO:2023-07-07 13h39.49 UTC:6400: Updating Max CVSS for CERT-Bund
md manage: INFO:2023-07-07 13h39.53 UTC:6400: Updating CERT-Bund CVSS max succeeded.
md manage: INFO:2023-07-07 13h39.56 UTC:6400: update_scap_end: Updating SCAP info succeededHowever, when I added a target for scanning, the following appeared in the log: event target:MESSAGE:2023-07-07 13h41.21 UTC:7368: Target Target for immediate scan of IP app.example.com - 2023-07-07 13:41:21 (6e1b7247-56c6-41ea-bf91-1abe2ed7dd84) has been created by admin
event task:MESSAGE:2023-07-07 13h41.21 UTC:7368: Status of task (54d76b19-39d7-4f6d-a21d-1c80cfbf279f) has changed to New
event task:MESSAGE:2023-07-07 13h41.21 UTC:7368: Task Immediate scan of IP app.example.com (54d76b19-39d7-4f6d-a21d-1c80cfbf279f) has been created by admin
event task:MESSAGE:2023-07-07 13h41.22 UTC:7368: Status of task Immediate scan of IP app.example.com (54d76b19-39d7-4f6d-a21d-1c80cfbf279f) has changed to Requested
event task:MESSAGE:2023-07-07 13h41.22 UTC:7368: Task Immediate scan of IP app.example.com (54d76b19-39d7-4f6d-a21d-1c80cfbf279f) has been requested to start by admin
event wizard:MESSAGE:2023-07-07 13h41.22 UTC:7368: Wizard quick_first_scan has been run by admin
md manage:WARNING:2023-07-07 13h41.22 utc:7413: sql_open: PQconnectPoll failed
md manage:WARNING:2023-07-07 13h41.22 utc:7413: sql_open: PQerrorMessage (conn): connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: remaining connection slots are reserved for non-replication superuser connections
md manage:WARNING:2023-07-07 13h41.22 utc:7413: init_manage_open_db: sql_open failed
md manage:WARNING:2023-07-07 13h41.22 utc:7412: sql_open: PQconnectPoll failed
md manage:WARNING:2023-07-07 13h41.22 utc:7412: sql_open: PQerrorMessage (conn): connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: remaining connection slots are reserved for non-replication superuser connections
md manage:WARNING:2023-07-07 13h41.22 utc:7412: init_manage_open_db: sql_open failedHere is my current system environment: Operating System: Windows 11 Pro |
|
Find decision but it's not a good way. After starting pg-gvm I connected to container and increase the value of max_connections (Thanks to this article). |
Downgrade did not work for me due to |
|
Same issue here, downgrading doesn't work. |
Same problem here, any solution? after restarting the gvmd the web back to normal, but then several seconds back to error again |
|
Do we have a document where it mentions what version of psql container |
|
I'm hoping /pull/2042 will solve this. When trying to reproduce I saw many gvmd processes building up when I was using GSA, and I guess the same issue is causing the database connections to run out. |
I tried to increase the number of max_connections to 300 still experience the error |
What's happening for me is that gvmd is keeping the connections from gsad open, and this is causing postgres to reach max_connections. /pull/2042 solves the issue. |
Thank you! I rebuilt gvmd with the patch applied and it seems to fix the issue, |
you can also tag the image of pg-gvm using: |
This wont change anything. pg-gvm stable is the same as pg-gvm:22, pg-gvm:22.5, pg-gvm:22.5.1 and also pg-gvm:latest. Additionally as I wrote pg-gvm doesn't not what you currently expect. You data in the database wont be rolled back to an older version. |
Are you tagging like this intentionally? If so may I ask about the reason for it? |
If you say so... What I reported was that using both tags with the same version works, It worked for me, it has been working on a fresh install with both greenbone/pg-gvm:22.5.1 and greenbone/gvmd:22.5.1 Again, do as you please, this is a community branch. |
Yes, I'm tagging like that based on the suggestions here. My docker-compose.yml: |
|
Maybe the Greenbone Community Containers still have same problem , if worker have free time, please fix it, thanks! |
Expected behavior
The system should boot and operate correctly.
Actual behavior
During the initial feed update of a community containers install, messages are being displayed indicating that psql has hit a connection limit.
Steps to reproduce
GVM versions
gsa: (gsad --version) - Greenbone Security Assistant 22.05.1
gvm: (gvmd --version) - Greenbone Vulnerability Manager 22.5.3
openvas-scanner: (openvas --version) - OpenVAS 22.4.1
gvm-libs: - gvm-libs 22.4.1~dev1
psql: psql (PostgreSQL) 13.11 (Debian 13.11-0+deb11u1)
Environment
Operating system:
Community Containers
Logfiles
The text was updated successfully, but these errors were encountered: