monthly logs

am I the only one to notice the file /usr/local/directadmin/data/task.queue doesnt exist making 3 of the crontab entries worthless.
 
Dixiesys said:
I can't find a server with properly rotating logs, granted I ain't looked at all 40 something DA servers but the ones I looked at didn't have rotating logs EXCEPT for those sites busting the 100 meg limit that rotates at least.

u can change that in /usr/local/directadmin/conf/directadmin.conf

and change log_rotate_size=10 so logs are rotated when the hit 10 meg
 
Richard said:
u can change that in /usr/local/directadmin/conf/directadmin.conf

and change log_rotate_size=10 so logs are rotated when the hit 10 meg

Ok, if I cahnge - what be doing with logs over 100meg?
 
from what I understand isnt rotating at small size not a fix, would it reset the bandwidth counter?

And what about the non existant task.queue file?
 
Richard said:
the log's rotation compress (tar.gz) and put in /home/user/domains/logs/file.tar.gz

I know that but when it rotates bw counter is reset, and the rotate by time interval does NOT work. So this leaves 1 of 3 situations.

1 - Rotate manually by deliberatly setting the rotate size low at the end of the month to ensure user's domt get unfairly charged for bandwidth.

2 - Set the rotate size low permanatly but this would leave no active bandwidth measurement in place.

3 - Leave how it is and give all users unlimited traffic to compensate since the traffic measurement is effectively broken (not ideal).

I see this as a major problem that needs looking at, maybe it is linked to the exim logs not been rotated problem, but I am going to look at the directadmin method, further analysis I see how task.queue works, the file doesnt exist and when it is made it is processed the following minute after creation. There is the following crontab entries

* * * * * root /usr/local/directadmin/dataskq
2 0-23/6 * * * root echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
5 0 * * * root /usr/sbin/quotaoff -a >/dev/null 2>&1; /sbin/quotacheck -aug >/dev/null 2>&1; /usr/sbin/quotaon -a >/dev/null 2>&1;
30 0 * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
40 1 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

apperently 'echo "action=reset&value=all" >> /usr/local/directadmin/data/task.queue' resets the logs but when I run this command it fails.

since /usr/local/directadmin/dataskq is what processes task.queue then that file I must presume is broken. Am I on the right track here?
 
from errortaskq log when I did the echo command

2004:10:30-18:26:00: Reset All has started
2004:10:30-18:26:00: Reset All has finished

but no rotation took place.
 
tried using mount to mount /usr/home to /home instead of symlink and this made no difference the echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue still does nothing for log rotation.

Also got issue of no exim log rotation, friend of mine who also runs directadmin had a full /var earlier, turns out exim_mainlog was 180 meg and the reject file was another 24 meg on top.

This log rotation issue I think should be atop priority for DA it defenitly seems an issue on FreeBSD boxes.
 
I think that someone should definitely start a list of problems on FreeBSD machines.

Logs are not rotating, Exim logs aren't showing... what else?
 
John from DA told me the crontab reset entry is only supposed to reset the tally's and not rotate logs, there is no monthly rotation for apache logs they only rotate by size. He also said exim log rotation bugfix is coming.
 
Chrysalis said:
John from DA told me the crontab reset entry is only supposed to reset the tally's and not rotate logs, there is no monthly rotation for apache logs they only rotate by size. He also said exim log rotation bugfix is coming.

Well, That's nice to say but was not the case back in May. The logs used to rotate monthly. In fact, there was a bugfix included in a recent version of DA (even though it was marked as not completed and has not been addressed since.)

I believe DA doesn't have any idea what they did to stop the monthly logs from rotating or how to fix it. Thus, the issue is being dropped and they are redefining how things are "supposed to" work.
 
LyricTung said:
Well, That's nice to say but was not the case back in May. The logs used to rotate monthly. In fact, there was a bugfix included in a recent version of DA (even though it was marked as not completed and has not been addressed since.)

I believe DA doesn't have any idea what they did to stop the monthly logs from rotating or how to fix it. Thus, the issue is being dropped and they are redefining how things are "supposed to" work.


I think exactly the same
 
I have only been using directadmin since august so I think I have never seen it working how you guys say, but if its true then yeah its dissapointing.
 
Back
Top