If you're noticing your system load is on the rise, as you can see that the "dataskq" binary is running at the top of the list (in "top"), this guide will help you debug what it's doing.
to see if the tally is being run. If Users continue to be added to the log (the logs is doing something), then it's likely just the nightly tally, which is normal (assuming the log continues to grow and isn't just stuck on one User)
The first thing to do, is to simply ask the dataskq what it's up to. To do this, type:
killall -USR1 dataskq
tail -n 10 /var/log/directadmin/errortaskq.log
What this will do is dump the running dataskq's current process location to the errortaskq.log. What that log output says will determine what to do next.
If the output makes reference to Maildir
along with a path, then what it likely means is that the mentioned path contains an over-sized inbox. Check that inbox and delete the messages, if the email user doesn't seem to be deleting them.
If the output makes reference to brute_force
or some related file, then the cause is likely the dataskq chewing on the system logs with many entries.
- First ensure you're using the latest version of DirectAdmin
ls -la brute_force*
We're checking for a large "brute_log_entries.list" file. If it seems to be "large" (say, over a meg in size), then that can slow things down. You can safely delete "brute_log_entries.list", as it's not part of the Brute Force Monitor's (BFM's) counting.. it's only for your own purposes, showing you what each attack was. DA will re-create this file automatically.
- if the brute_log_entries.list contiues to grow and you'd like it to keep itself smaller, go to:
Admin Level -> Admin Settings
and lower the value for:
Clear failed login attempts from log X days after entry was made.
to something around 2 days.
Also, increasing the values for:
Notify Admins after an IP has X login failures on any account.
Notify Admins after a User has X login failures from any IP.
will reduce the number of entries made into the brute_log_entries.list file.