errortaskq.log - Timestamp different, overwriting anyway-errors

BBM

Verified User
Joined
Jun 8, 2013
Messages
416
Location
Dutch Mountains
Right after 'coupling' BFM with CSF by help of the steps on;
https://www.plugins-da.net/info/how-to-block-ips-with

... the errortasklog started showing this message every few minutes since then, filling up the logfile;
Code:
ConfigFile::writeFile(./data/admin/brute_user.data) : Timestamp from when it was read is different, overwriting anyway

Did some searching but could not find a solution to this.

I noticed ownership of 'brute_user.data' was diradmin:root. Tried changing ownership of the file a few times, but it seems to be changed back automaticly (I presume by DA?) to diradmin:root.
Is this correct?


DA version is 14.7
 
Hello,

I guess this is what happened:

1. Directadmin has read the file and remembered its mtime.
2. Another Directadmin process has added records into it or removed some.
3. The first initial process noticed mtime was changed when it wanted to write data into it and dropped a warning into logs.

I hope John will clarify that.

One else thing I can say, that ownership of the file is correct, directadmin have its files owned by diradmin, so there is nothing to worry about.
 
I'm not too worried but I don't like to see the logs filling up with something that wasn't happening before (only an occassional message showed, but not evey 2-3 minutes like now. Feels like a waste of resources.

One thing I noticed is that the ownership and group-tags of 'brute_force.data' seems to change from diradmin:root to diradmin:direadmin at times.
Some time yesterday, it was diradmin:diradmin, and now it's diradmin:root again.
 
I know this is an old post, but still found no solution that works. I also have the exact same error and came to this thread. I have deleted the brute_user.data, changed ownership to diradmin.root only to find that upon the next cronjob it reverts back to diradmin.diradmin and the message keep piling up. The file itself remains empty.

Does anyone have a clue what I can do about this?

Kind Regards,
Rogier
 
Rogier,

Are you using IPSET already?

Code:
grep ^LF_IPSET /etc/csf/csf.conf

Potentially using IPSET you can speed up CSF.

What do you see when running the following commands as root?

Code:
csf -t | grep ^DENY -c
Code:
time csf -d 1.2.3.4
Code:
time csf -dr 1.2.3.4
Code:
time csf -td 1.2.3.4
Code:
time csf -tr 1.2.3.4
Code:
time csf -dr 1.2.3.4
 
Same case,

even I use IPSET - nothing change

Code:
csf -t | grep ^DENY -c
115
Code:
time csf -d 1.2.3.4
Adding 1.2.3.4 to csf.deny and iptables DROP...
DROP all opt -- in !lo out * 1.2.3.4 -> 0.0.0.0/0
LOGDROPOUT all opt -- in * out !lo 0.0.0.0/0 -> 1.2.3.4

real 0m0.855s
user 0m0.548s
sys 0m0.184s

Code:
time csf -dr 1.2.3.4
Removing rule...
DROP all opt -- in !lo out * 1.2.3.4 -> 0.0.0.0/0
LOGDROPOUT all opt -- in * out !lo 0.0.0.0/0 -> 1.2.3.4

real 0m0.657s
user 0m0.484s
sys 0m0.148s

Code:
time csf -td 1.2.3.4
DROP all opt -- in !lo out * 1.2.3.4 -> 0.0.0.0/0
csf: 1.2.3.4 blocked on port * for 3600 seconds inbound

real 0m0.538s
user 0m0.396s
sys 0m0.112s

Code:
time csf -tr 1.2.3.4
DROP all opt -- in !lo out * 1.2.3.4 -> 0.0.0.0/0
csf: 1.2.3.4 temporary block removed
csf: There are no temporary IP allows

real 0m0.552s
user 0m0.468s
sys 0m0.048s

Code:
time csf -dr 1.2.3.4
csf: 1.2.3.4 not found in csf.deny

real 0m0.652s
user 0m0.480s
sys 0m0.108s

Any solutions?
 
Back
Top