Authentication very slow (7-11 sec) #5645
Comments
mkrecek234
changed the title
|
Is this a permanent issue or does it occur after the mailcow stack is running for some time? I had a similar issue where logins were fast after a fresh start of the stack, but started to take several seconds after some time. In my case this was related to the innodb buffer pool of the mysql db. See details here: https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html After adjusting the values for innodb_buffer_pool_size, innodb_old_blocks_time, read_rnd_buffer_size and some other the issue went away. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
milkmaker
added
the
stale
|
Unfortunately, it also is so extremely slow after a fresh restart, so probably no buffering issue... |
milkmaker
removed
the
stale
|
I have recently noticed a similar problem, My problem is that I cannot find any logs in connection with the login. In the mailcow UI logs, I can only see that the login was ultimately successful, but not how long the login took. Any help would be appreciated... EDIT: Issue is not limited to FIDO2 login and happens without 2FA as well... EDIT 2: My impression is rather that only the first login takes so long and every further attempt after that works faster again in the short term. Exactly the other way around, so to speak, as described by @beerlao . |
|
I can confirm your observations, I'm still experiencing the problem even after fine tuning the database. The symptoms: First login takes ages and sometimes runs into the timeout of the reverse proxy. My awful workaround is running the following cronjob every 5 minutes for the affected accounts: curl -X GET http://localhost:8088/api/v1/get/last-login/$USER/7 -H 'Content-Type:application/json' -H 'X-API-Key:$API_KEY' This one logs into the account and ask for the last 7 logins. |
|
I can agree 100% with the symptoms described. What surprises me the most is that the problem only seems to exist for some users and not for everyone. |
|
I also have this same issue, but only affects 1 user account. Deleting the user account and recreating does not fix it. |
|
I have the same issue. I am not familiar with the mailcow codebase, but I assume this is used to get the country of origin of each IP shown in the login history. EDIT: |
|
So, Which declares the last login as a global variable. This in turn calls: Which, for each IP used to login in the last 7 days tries to get the cached location in Redis, and calls https://dfdata.bella.network/lookup if the value isn't cached. At first glance, removing: seems to solve the issue without having any obvious adverse effect. The corresponding variable: doesn't seem to be used anywhere. A double-check would be welcome, I'd like to know if |
|
While I dont know if I should remove last_login, I went ahead and removed it. The single user account I had issues with now will login instantly. I did notice when going to the 'App_Passwords' tab or the 'Temporary email aliases tab' it does have a loading screen for about 30 seconds now. But thank you @PierrePlt for the tip. Im leaving it removed for now unless I see any adverse side affects. |
|
I guess the delay when clicking on another tab comes from the call to api/v1/get/last-login that still takes a while even though it's not blocking the loading of the main user page anymore mailcow-dockerized/data/web/inc/functions.inc.php Lines 285 to 311 in 36b5ccc That's not an acceptable long-term solution, but if the loading time is too big of an issue that should fix it for now |
|
I have the issue that I move though many different wifi networks throughout the day at university, and my device gets a different IPv6 Addresses every time. Would it be possible that at least only the /64 IPv6 Network gets looked up and cached? Most likely all of the IPs in one /64 are always from one country or even one customer. |
Contribution guidelines
I've found a bug and checked that ...
Description
Logs:
You can see that there are 8 seconds between awaiting_tfa_confirmation and verified_totp_login.
This issue also exists if there is no two-factor login what I can see with other logins.
Steps to reproduce:
Which branch are you using?
master
Operating System:
Ubuntu 22.04
Server/VM specifications:
AMD EPYC 7282 16-Core Processor, 6 cores, 16 GB
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
None
Docker version:
24.0.7, build afdd53b
docker-compose version or docker compose version:
1.29.2, build unknown
mailcow version:
2024-01
Reverse proxy:
Apache
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check:
The text was updated successfully, but these errors were encountered: