nach Update: GUI kurz nach dem Neustart nicht mehr erreichbar
- Thread starter Morpheu5
- Start date
Habt ihr schon versucht den checkmk Check für TCP Port 8007 durch einen HTTP Verbindungscheck zu ersetzen? Oder die Checkzeitplanung zu erhönen (Standard ist ja oft alle fünf Sekunden, was ändert sich wenn man das auf eine Minute hoch dreht)?
Did you also restart PBS after disabling Uptime Kuma?
In my case I also had to contact the other location from where my server is also pinged with Uptime Kuma.
1. In my case, I open a real HTTPS connection via Uptime Kuma, I left it on for all tests in order to cause the problem. I am quite sure that this is the culprit, because you can see the stepwise increase in load for each probe connection.
2. Even if the test is done only once per 5 minutes, the processes will hang. In my case, with 4 cores, it needed 4 * 5 minutes until the machine was saturated. You do not need an overwhelming number of probes to cause this, because each probe hogs one thread.
3. I always rebooted the PBS after any package install and whenever it hung. Probably killing the proxmox-backup-proxy process would eliminate the hang.
4. I had one VM instance that was being probed by uptime-kuma that did not lock up - in that case, there was an official ("real") certificate in place, such that I did not have to ignore TLS errors. Probably the problem has to do with an incomplete TLS negitation like it would also occur with a plain TCP probe.
5. I think one could fix the problem for now by:
Later, when a version > 3.2.8-1 becomes available, you have to release the package again:
2. Even if the test is done only once per 5 minutes, the processes will hang. In my case, with 4 cores, it needed 4 * 5 minutes until the machine was saturated. You do not need an overwhelming number of probes to cause this, because each probe hogs one thread.
3. I always rebooted the PBS after any package install and whenever it hung. Probably killing the proxmox-backup-proxy process would eliminate the hang.
4. I had one VM instance that was being probed by uptime-kuma that did not lock up - in that case, there was an official ("real") certificate in place, such that I did not have to ignore TLS errors. Probably the problem has to do with an incomplete TLS negitation like it would also occur with a plain TCP probe.
5. I think one could fix the problem for now by:
Bash:
apt-get install proxmox-backup-server=3.2.7-1
apt-mark hold proxmox-backup-server
rebootLater, when a version > 3.2.8-1 becomes available, you have to release the package again:
Bash:
apt-mark unhold proxmox-backup-server
Last edited:
Hi @meyergru, you saved my skin man.
I had the same issues of you after upgrade couple PBS servers. From 5 servers, on two I had the same issues caused by 100% of CPU usage on all cores where the process "proxmox-backup-proxy" was running like crazy.
As soon I did the downgrade like you said and reboot, my issues gone and now I'm back to normal life.
Thank you so much my friend for share your tips. This was priceless, again, thank you!!!
I had the same issues of you after upgrade couple PBS servers. From 5 servers, on two I had the same issues caused by 100% of CPU usage on all cores where the process "proxmox-backup-proxy" was running like crazy.
As soon I did the downgrade like you said and reboot, my issues gone and now I'm back to normal life.
Thank you so much my friend for share your tips. This was priceless, again, thank you!!!
Last edited:
Follow the commands below as stated by @meyergru and you can back to use your PBS normally until Proxmox team releases a new version fixing the issue:
apt-get install proxmox-backup-server=3.2.7-1
apt-mark hold proxmox-backup-server
reboot
As soon a new fixed version is available and you want to upgrade, use this command to unhold updates for proxmox-backup-server package:
apt-mark unhold proxmox-backup-server
And then you will be able to run "apt update" and "apt dist-upgrade" later in the future again. It's what you should to do, do not keep your PBS down if there's a workaround to overcome that temporary issue.
Last edited:
Yeah. As soon you downgrade PBS to the prior version this bad behavior is gone.
Vielen Dank für die Anleitung, hat perfekt geklappt ... Danke
Das Problem sollte mit dem proxmox-backup-server Paket in der Version 3.2.9-1 wieder behoben sein.
Diese Version ist zurzeit im
Diese Version ist zurzeit im
pbstest Repository verfügbar.
Last edited:
You’re right, it’s fixed on pbstest repository with the version 3.2.9-1. I just upgraded one of my affected servers and there’s no more problem. The CPU usage of proxmox-backup services are doing its job flawless and without any impact on the server’s performance.
Thank you so much for that heads up.
Yes, I can confirm this fixes it. I assume it is this patch: https://git.proxmox.com/?p=proxmox-...ff;h=b3675d867f98de58292fdedded4e866dfcb8dd33
For those of you that do not want to switch to pbstest, you can also follow these steps:
The proxmox-backup-proxy will automatically be restarted, you do not need to reboot.
The first line is to release the hold on the package such that you will get updates later on.
For those of you that do not want to switch to pbstest, you can also follow these steps:
Code:
apt-mark unhold proxmox-backup-server
curl -o proxmox-backup-server_3.2.9-1_amd64.deb http://download.proxmox.com/debian/pbs/dists/bookworm/pbstest/binary-amd64/proxmox-backup-server_3.2.9-1_amd64.deb
dpkg -i proxmox-backup-server_3.2.9-1_amd64.deb
rm -f proxmox-backup-server_3.2.9-1_amd64.debThe proxmox-backup-proxy will automatically be restarted, you do not need to reboot.
The first line is to release the hold on the package such that you will get updates later on.
Last edited:
Just for completeness' sake: Yes, that's the one pulling in the new enough proxmox-rest-server that includes the actual fix:
https://git.proxmox.com/?p=proxmox.git;a=commitdiff;h=dc9531d3023e8975789fc36ab17f8aa9c2907ac5
Thanks for reporting this and all of your feedback here!