• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Login to the plesk panel takes a long time

Dork

Regular Pleskian
Server operating system version
CentOS Linux 7.9.2009 (Core)
Plesk version and microupdate number
18.0.49 Update #2
snce a few weeks - the login to the plesk panel takes a lon time
Even the click on a link that is offert by the panel is very slow.
I need some advice to change that.
 
Checked server's resources? High resource usage? Tried restarting the server?
 
Could be a DNS problem, too. You can check if the hostname has a DNS entry for both IPv4 and IPv6, then check if you can reach the host by both. Sometimes one is missing. Failover mechanisms will then use the other, but this will take several seconds until it happens which makes each request appear extra slow.
 
Hi,

Do you have any updates available for Plesk and extensions? If an update available for the Plesk Monitoring extension, I would suggest to install it because the last release contains a bug-fix for a performance issue.

I also would suggest open the login form with Chrome browser (or similar), activate "Dev. Console" (usually F12), submit the login form and check what steps take long time, e.g. there is a screenshot from my Plesk,

1675713802588.png
 
Last edited:
Could be a DNS problem, too. You can check if the hostname has a DNS entry for both IPv4 and IPv6, then check if you can reach the host by both. Sometimes one is missing. Failover mechanisms will then use the other, but this will take several seconds until it happens which makes each request appear extra slow.
The server uses only IPv4
 
Hi,

Do you have any updates available for Plesk and extensions? If an update available for the Plesk Monitoring extension, I would suggest to install it because the last release contains a bug-fix for a performance issue.

I also would suggest open the login form with Chrome browser (or similar), activate "Dev. Console" (usually F12), submit the login form and check what steps take long time, e.g. there is a screenshot from my Plesk,

View attachment 22589
Thats what I get from the browser:
downloadable font: kern: Too large subtable (font-family: "Open Sans" style:normal weight:600 stretch:100 src index:2)
downloadable font: Table discarded (font-family: "Open Sans" style:normal weight:600 stretch:100 src index:2)
 
Thats what I get from the browser:
downloadable font: kern: Too large subtable (font-family: "Open Sans" style:normal weight:600 stretch:100 src index:2)
downloadable font: Table discarded (font-family: "Open Sans" style:normal weight:600 stretch:100 src index:2)
Those errors seem to stem from an issue with the Open Sans font in FireFox. Although I am not sure if that's also the cause for the long loading time you are experiencing.

Are you using FireFox? If you do, can you test with another browser to see if Plesk still takes a long time to load?
 
Last edited:
snce a few weeks - the login to the plesk panel takes a lon time
Even the click on a link that is offert by the panel is very slow.
I need some advice to change that.
Postfix is under heavy attacks and secure log contains a lot of pam_systemd(crond:session): Failed to create session: connection timed out
messages contains a lot of agent360[150]: ping: socket: Operation not permitted
I am helpless.

 
Are you using Fail2Ban? If not - might be an option for you to block the attackers just before they get into the services.
 
Yes - I use it; but thanks for the hint
Alright - so you just have to figure out which ip addresses are attacking most.
If you are running on CentOS/AlmaLinux and Plesk with dovecot, you could simple run that command via ssh:
Bash:
grep "SASL LOGIN authentication failed: authentication failure" /var/log/maillog | awk '{print $7}' | cut -d "[" -f2 | cut -d "]" -f1 | sort -n | uniq -c | sort -nr
With that, you will get the most tried IPs of the attacker (number of failures and it's ip).
After that, you could simply ban the ip with the plesk firewall, fail2ban or even with iptables directly.

EDIT:
I also noticed the problem if the Google Authenticator extension is installed - even if it's not used the login might be slow.
 
Alright - so you just have to figure out which ip addresses are attacking most.
If you are running on CentOS/AlmaLinux and Plesk with dovecot, you could simple run that command via ssh:
Bash:
grep "SASL LOGIN authentication failed: authentication failure" /var/log/maillog | awk '{print $7}' | cut -d "[" -f2 | cut -d "]" -f1 | sort -n | uniq -c | sort -nr
With that, you will get the most tried IPs of the attacker (number of failures and it's ip).
After that, you could simply ban the ip with the plesk firewall, fail2ban or even with iptables directly.

EDIT:
I also noticed the problem if the Google Authenticator extension is installed - even if it's not used the login might be slow.
Thanks - that's nice but doesn't solve anything
 
snce a few weeks - the login to the plesk panel takes a lon time
Even the click on a link that is offert by the panel is very slow.
I need some advice to change that.
I did a reinstall of polkit, dbus and systemd but nothing helps
 
Now I found this:
Unregistered Authentication Agent for unix-process:31476:25646716 (system bus name :1.3099, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale de_DE.utf8) (disconnected from bus)

but polkit is aktiv
 
If none of the above suggestions helped, especially if the one by @AYamshanov did not yield a path to the cause, I suggest to open a ticket with Plesk support.
 
If none of the above suggestions helped, especially if the one by @AYamshanov did not yield a path to the cause, I suggest to open a ticket with Plesk support.
I purchased it from a Plesk partner and so:
If you have purchased a Plesk license from one of Plesk partners, technical support should be provided by them. Plesk partners are fully trained and deliver best-in-the-industry support for Plesk products running on their infrastructure.
 
Back
Top