High CPU load from dataskq

Monsantosucks

Monsantosucks

Verified User
Joined
Nov 10, 2014
Messages
12
I'm trying to solve a CPU load issue with dataskq. The CPU load is about 5 times higher than the average for this year. I have found several topics (https://help.directadmin.com/item.php?id=402) related to my problem but I can't seem to make any progress.

What I did find was a large brute_log_entries.list file, which was 533MB. I deleted this file and a new one was created (now 13MB).
I killed the process and tried to find out what is causing the load like this:

# killall -USR1 dataskq
# tail -n 10 /var/log/directadmin/errortaskq.log

2021:09:19-07:30:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:19-07:30:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-00:37:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-00:37:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-00:37:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-00:41:01: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-01:46:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-01:46:02: access is not a valid username because it matches the directadmin.conf option secure_access_group
2021:09:20-16:38:03: removing old lock: ./data/admin/brute.conf.lock (age: 10801 seconds) this caller='check_brute_force_logs', old creation info: lock created Mon Sep 20 13:38:02 2021
2021:09:20-16:38:21: access is not a valid username because it matches the directadmin.conf option secure_access_group

When I open the errortaskq.log file manually there is also this line:
2021:09:20-19:14:03: Dataskq [14446] USR1 signal: Currently processing: check_brute_force_logs: done User sorting : getDirFilesAndDirs(/usr/local/directadmin/plugins, *tlf, *tdlf, (null)) : done

Running DirectAdmin 1.62.4 on CentOS 7.
Any suggestions are welcome!
 
you seem to have a hosting user called "access".
if that's the case, you have a group conflict.
directadmin uses a group called " access " by default for services.

option one:
rename the user called "access", call it something else.
option two:
create a new group, call it for example "sysaccess"
add the group to the following users:
apache,nobody,mail,majordomo,daemon,ftp
edit /usr/local/directadmin/conf/directadmin.conf
change the line
secure_access_group=access
to
secure_access_group=sysaccess
restart directadmin.
 
I double checked but there is no hosting user called "access". The server is dedicated and I am the only one allowed to create users.

Do you think the access user message is what causes the high cpu load from dataskq?
 
I think some kind of brute force log might be the problem. Even though I delete the brute_log_entries.list and brute_user.data the Brute Force page is loading for more than 15 minutes before any results are shown: mydomain.com:2222/CMD_BRUTE_FORCE_MONITOR

I can now see half of the page but the data for users that have failed to login go months back. So I am wondering, where does Directadmin get this data if not from brute_user.data? The size of the newly created brute_user.data file is 5M instantly.
 
The problem seems to be fixed with a block on an ip-range from Iran which caused about 10 new lines per second (exim login attempts) in the brute force logs. This was too much to handle for the dataskq proces. CPU load is now 1/8th of what is was before.
 
/usr/local/directadmin/directadmin taskq --syslog high cpu usage every 20-30 second. is this an attack?
 
You must log in or register to reply here.
Back
Top