[GH-ISSUE #236] GUI Stops responding 0.2.21 - postgres restart fixes it #2089

Closed
opened 2026-03-14 02:26:10 +03:00 by kerem · 13 comments
Owner

Originally created by @bbrendon on GitHub (Jan 7, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/236

GUI has spinning wheels and doesn't load. Restarting postgres fixes it. This has happened a few times now. I haven't figured out what triggers it.

postgres has tons of these

2021-01-07 13:30:42.105 PST [31297] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections
2021-01-07 13:30:42.105 PST [31295] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections
2021-01-07 13:30:42.109 PST [31294] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections
2021-01-07 13:30:42.118 PST [31299] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections
2021-01-07 13:30:42.128 PST [31301] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections
2021-01-07 13:30:42.134 PST [31300] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections
2021-01-07 13:30:42.141 PST [31303] kwjmlcmm@tacticalrmm FATAL:  remaining connection slots are reserved for non-replication superuser
connections

celery has some of these

django.db.utils.OperationalError: FATAL:  remaining connection slots are reserved for non-replication superuser connections
Originally created by @bbrendon on GitHub (Jan 7, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/236 GUI has spinning wheels and doesn't load. Restarting postgres fixes it. This has happened a few times now. I haven't figured out what triggers it. postgres has tons of these ``` 2021-01-07 13:30:42.105 PST [31297] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections 2021-01-07 13:30:42.105 PST [31295] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections 2021-01-07 13:30:42.109 PST [31294] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections 2021-01-07 13:30:42.118 PST [31299] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections 2021-01-07 13:30:42.128 PST [31301] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections 2021-01-07 13:30:42.134 PST [31300] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections 2021-01-07 13:30:42.141 PST [31303] kwjmlcmm@tacticalrmm FATAL: remaining connection slots are reserved for non-replication superuser connections ``` celery has some of these ``` django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections ```
kerem closed this issue 2026-03-14 02:26:24 +03:00
Author
Owner

@rtwright68 commented on GitHub (Jan 8, 2021):

Exactly what we are seeing on our 479 agent server. Boosted CPU and RAM.

<!-- gh-comment-id:756675214 --> @rtwright68 commented on GitHub (Jan 8, 2021): Exactly what we are seeing on our 479 agent server. Boosted CPU and RAM.
Author
Owner

@bradhawkins85 commented on GitHub (Jan 8, 2021):

Storage speed may play a part in this, not saying it is the issue but may be related.
Is the database on an SSD?

<!-- gh-comment-id:756694797 --> @bradhawkins85 commented on GitHub (Jan 8, 2021): Storage speed may play a part in this, not saying it is the issue but may be related. Is the database on an SSD?
Author
Owner

@rtwright68 commented on GitHub (Jan 8, 2021):

Yes, my ESXi hosts are fully SSD (HPE 380's).
Everything was working great prior to v0.2.20
Definitely noticed the spinning and the issues connecting to Agents via Mesh after that update.
Now on 0.2.21

<!-- gh-comment-id:756696125 --> @rtwright68 commented on GitHub (Jan 8, 2021): Yes, my ESXi hosts are fully SSD (HPE 380's). Everything was working great prior to v0.2.20 Definitely noticed the spinning and the issues connecting to Agents via Mesh after that update. Now on 0.2.21
Author
Owner

@dinger1986 commented on GitHub (Jan 8, 2021):

I have noticed my host being slower since the update to 0.2.20 but also had issues with disk space so had put it down to that.

Space is fine now!

<!-- gh-comment-id:756698861 --> @dinger1986 commented on GitHub (Jan 8, 2021): I have noticed my host being slower since the update to 0.2.20 but also had issues with disk space so had put it down to that. Space is fine now!
Author
Owner

@bradhawkins85 commented on GitHub (Jan 8, 2021):

Are there any errors showing up in the browser console in dev tools?

<!-- gh-comment-id:756702993 --> @bradhawkins85 commented on GitHub (Jan 8, 2021): Are there any errors showing up in the browser console in dev tools?
Author
Owner

@rtwright68 commented on GitHub (Jan 8, 2021):

Checked the debug log, multiple agents were reporting data overdue (across all our VPNs and locally on the same LAN):

2021-01-08 13:45:12.600 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCC-INK, attempting recovery
2021-01-08 13:45:12.577 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on DCB-KIOSK1, attempting recovery
2021-01-08 13:45:12.570 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on LAPTOP-RCRLC, attempting recovery
2021-01-08 13:45:12.561 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on DRK-WEB, attempting recovery
2021-01-08 13:45:12.513 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on MJ03M68T, attempting recovery
2021-01-08 13:45:12.502 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on DESKTOP-51767, attempting recovery
2021-01-08 13:45:12.496 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on EMP-SQL1, attempting recovery
2021-01-08 13:45:12.464 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCC-BRIX-Martin, attempting recovery
2021-01-08 13:45:12.435 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on TNP-DIGSIGN1, attempting recovery
2021-01-08 13:45:12.430 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on ASC-DGSRBV, attempting recovery
2021-01-08 13:45:12.428 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on ROC-DAD9J1, attempting recovery
2021-01-08 13:45:12.419 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCC-RDS2, attempting recovery
2021-01-08 13:45:12.383 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCI-FM1, attempting recovery

Some agents recover then it goes to the spinner and I have to restart the VM. Ugh.

After a restart, all the agents report back (data received) and things function normally.

<!-- gh-comment-id:756768883 --> @rtwright68 commented on GitHub (Jan 8, 2021): Checked the debug log, multiple agents were reporting data overdue (across all our VPNs and locally on the same LAN): 2021-01-08 13:45:12.600 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCC-INK, attempting recovery 2021-01-08 13:45:12.577 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on DCB-KIOSK1, attempting recovery 2021-01-08 13:45:12.570 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on LAPTOP-RCRLC, attempting recovery 2021-01-08 13:45:12.561 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on DRK-WEB, attempting recovery 2021-01-08 13:45:12.513 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on MJ03M68T, attempting recovery 2021-01-08 13:45:12.502 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on DESKTOP-51767, attempting recovery 2021-01-08 13:45:12.496 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on EMP-SQL1, attempting recovery 2021-01-08 13:45:12.464 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCC-BRIX-Martin, attempting recovery 2021-01-08 13:45:12.435 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on TNP-DIGSIGN1, attempting recovery 2021-01-08 13:45:12.430 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on ASC-DGSRBV, attempting recovery 2021-01-08 13:45:12.428 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on ROC-DAD9J1, attempting recovery 2021-01-08 13:45:12.419 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCC-RDS2, attempting recovery 2021-01-08 13:45:12.383 | INFO | agents.tasks:_check_agent_service:25 - Detected crashed tacticalagent service on BCI-FM1, attempting recovery Some agents recover then it goes to the spinner and I have to restart the VM. Ugh. After a restart, all the agents report back (data received) and things function normally.
Author
Owner

@bbrendon commented on GitHub (Jan 8, 2021):

Right now I only have 20 agents and load is very low (0.05 to 0.10). Swap used is 0.

The server is basically fine until its suddenly not.

Unfortunately I've only used mysql in the past. Digging into postgres has proven to be quite a learning curve so far.

<!-- gh-comment-id:756873330 --> @bbrendon commented on GitHub (Jan 8, 2021): Right now I only have 20 agents and load is very low (0.05 to 0.10). Swap used is 0. The server is basically fine until its suddenly not. Unfortunately I've only used mysql in the past. Digging into postgres has proven to be quite a learning curve so far.
Author
Owner

@rtwright68 commented on GitHub (Jan 8, 2021):

Our server is losing its mind today. I ran the backup script hoping a vacuum would help. Its essentially non-responsive on the GUI and we are receiving constant notifications of data overdue and some returning to normal.
I shut it all the way down a couple times and brought it back up but its a mess today for some reason.

<!-- gh-comment-id:756889180 --> @rtwright68 commented on GitHub (Jan 8, 2021): Our server is losing its mind today. I ran the backup script hoping a vacuum would help. Its essentially non-responsive on the GUI and we are receiving constant notifications of data overdue and some returning to normal. I shut it all the way down a couple times and brought it back up but its a mess today for some reason.
Author
Owner

@wh1te909 commented on GitHub (Jan 8, 2021):

please update to 0.2.22, restart VM and let me know if issue is still present

don't worry about the "detected crashed service" messages in debug log that's normal, is just a temp fix for now while im making some big changes to agent

<!-- gh-comment-id:756919754 --> @wh1te909 commented on GitHub (Jan 8, 2021): please update to 0.2.22, restart VM and let me know if issue is still present don't worry about the "detected crashed service" messages in debug log that's normal, is just a temp fix for now while im making some big changes to agent
Author
Owner

@rtwright68 commented on GitHub (Jan 8, 2021):

Fantastic, thanks for the rapid fix! My guys were all having withdrawal, lol

<!-- gh-comment-id:756925375 --> @rtwright68 commented on GitHub (Jan 8, 2021): Fantastic, thanks for the rapid fix! My guys were all having withdrawal, lol
Author
Owner

@rtwright68 commented on GitHub (Jan 8, 2021):

please update to 0.2.22, restart VM and let me know if issue is still present

don't worry about the "detected crashed service" messages in debug log that's normal, is just a temp fix for now while im making some big changes to agent

We are good now!

<!-- gh-comment-id:756963302 --> @rtwright68 commented on GitHub (Jan 8, 2021): > please update to 0.2.22, restart VM and let me know if issue is still present > > don't worry about the "detected crashed service" messages in debug log that's normal, is just a temp fix for now while im making some big changes to agent We are good now!
Author
Owner

@wh1te909 commented on GitHub (Jan 9, 2021):

@bbrendon closing as this was fixed in 0.2.22

<!-- gh-comment-id:757374418 --> @wh1te909 commented on GitHub (Jan 9, 2021): @bbrendon closing as this was fixed in 0.2.22
Author
Owner

@rtwright68 commented on GitHub (Jan 12, 2021):

TRMM worked great over the weekend, but went completely off the rails yesterday. Restart did not affect it as well. Still suspecting a memory leak? Had to shut down the VM due to the continuous "data overdue" and then "data received" messages. Spinning wheel and lack of agent access as well.

<!-- gh-comment-id:758635979 --> @rtwright68 commented on GitHub (Jan 12, 2021): TRMM worked great over the weekend, but went completely off the rails yesterday. Restart did not affect it as well. Still suspecting a memory leak? Had to shut down the VM due to the continuous "data overdue" and then "data received" messages. Spinning wheel and lack of agent access as well.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tacticalrmm#2089
No description provided.