|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)
2) The first thing to do, is to simply ask the dataskq what it’s up to. To do this, type:
killall -USR1 dataskq
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.
3) 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.
4) 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.
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:
and lower the value for:
to something around 2 days.
will reduce the number of entries made into the brute_log_entries.list