"dataskq" eating 100% of processor resources

Abilnet

Abilnet

Verified User
Joined
Apr 21, 2010
Messages
15
Location
Sunny Spain
I've read the forums, asked Google and taken a look at the knowledgebase, but still not found any solution. Helping hands & tips highly appreciated!

* Ubuntu 10.04 LTS server Intel Core 2 Duo 2.5Ghz 4GB RAM (up to date)
* DA 1.39.1
* The server has been running smoothly almost an year, but (maybe) after recent brute force attacks the problem started
* "dataskq" eating 100% of processor resources. It will continue for ever, but when rebooting the server, the problem disappears... but comes back soon (maybe after half an hour or so)

All help appreciated!

/usr/local/directadmin/data/task.queue
---> empty / no exist

/etc/cron.d/directadmin_cron
Code: 
#* * * * * root /usr/local/directadmin/dataskq
* * * * * root if [ "`ps ax | grep -v grep | grep -c dataskq`" -eq 0 ]; then /usr/local/directadmin/dataskq; fi;
2 0-23/6 * * * root echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
#5 5 * * 0 root /sbin/quotaoff -a; /sbin/quotacheck -augm; /sbin/quotaon -a;
10 0 * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
20 4 1 * * root echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue
0 4 * * * root echo 'action=check&value=license' >> /usr/local/directadmin/data/task.queue

/var/log/directadmin/error.log
Code: 
2011:06:28-23:59:45: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:09:00: Timeout from from 80.26.236.229 : last flagged: Send::loadLangFile(./data/skins/enhanced/footer.html) : ./data/skins/enhanced/lang/en/footer.html : pre-exist
2011:07:01-03:09:00: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:09:00: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:10:28: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:10:28: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:10:28: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:10:28: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-03:43:33: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-04:25:20: Socket write error: fd is connected to a pipe or socket whose reading end is closed.  When this  happens the writing process will also receive a SIG_PIPE signal.  (Thus, the write return value is seen only if  the program catches, blocks or ignores this signal.)
2011:07:01-11:49:41: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-11:51:12: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-11:52:28: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
2011:07:01-14:03:24: Timeout from from 80.26.236.229 : last flagged: Request::readAndProcess(*skt, 80.26.236.229, 80.26.236.229)
 
Thanks Peter for the tip, appreciated.

I'd edit /usr/local/directadmin/conf/directadmin.conf (Ubuntu) to disable bruteforce:

Code: 
brute_force_time_limit=120
brutecount=50
bruteforce=0

...then restarted DA, but unfortunately "dataskq" is still sucking 100% of CPU (it's been running more than 20 hour now... seems that even rebooting the server does not clear it out?)

Any ideas what to do?
 
Thanks again Peter, appreciated. I can start the DA debug mode, no problem, but as a newbie I have no idea what to do there.

I'm afraid I need some more hand holding here, thanks :o

AN UPDATE:
Server load seems to become to normal. I did not do anything else than described above... maybe DA/dataskq had to finish something first before getting the situation to normal?

Thanks for your help Peter, appreciated!
 
Last edited:
You must log in or register to reply here.
Back
Top