Bandwith not reset !!!

M

mrcancel

Verified User
Joined
Oct 18, 2004
Messages
13
I am using linux server and directadmin control panel but bandwith not reset !!! Help me !
 
Giving us more information will help troubleshoot your problem ;)

Can you reset the bandwidth by initiating the proper command from the command line?
Code: 
echo "action=reset&value=all" >> /usr/local/directadmin/data/task.queue
 
jmstacey said:
Giving us more information will help troubleshoot your problem ;)
Click to expand...
Unfortunately, there is nowhere to get more information cos there is no error message in DA logs, etc.
Reset executed from crontab - but BW just not resetted.
This thing happens _every_ month with one of our servers.
But today 1.04.2005 - bandwith not resetted on 3 of 6 our servers.
WTF ?! Why I shoud run reset command manually every month?

1st server (RH9.0):
from /var/log/cron:
Code: 
...
Apr  1 03:10:00 alpha CROND[17340]: (root) CMD (echo 'action=tally&value=all' >>
 /usr/local/directadmin/data/task.queue)
...
Apr  1 04:20:01 alpha CROND[23629]: (root) CMD (echo 'action=reset&value=all' >>
 /usr/local/directadmin/data/task.queue)
...

from /var/log/directadmin/system.log:
Code: 
...
2005:04:01-03:10:01: Tally All Begin
...
2005:04:01-03:38:31: Tally All Complete
2005:04:01-03:39:14: httpd restarted
2005:04:01-08:56:44: httpd restarted
...

There is no entries in /var/log/directadmin/error.log or /log/directadmin/errortaskq.log after 03:39 at all.

2nd server (FreeBSD 4.10):
from /var/log/cron:
Code: 
...
Apr  1 00:30:00 gamma /usr/sbin/cron[44191]: (root) CMD (echo 'action=tally&valu
e=all' >> /usr/local/directadmin/data/task.queue)
...
Apr  1 01:40:00 gamma /usr/sbin/cron[52596]: (root) CMD (echo 'action=reset&valu
e=all' >> /usr/local/directadmin/data/task.queue)
...

from /var/log/directadmin/system.log:
Code: 
2005:04:01-00:30:01: Tally All Begin
...
2005:04:01-00:43:07: Tally All Complete
2005:04:01-00:44:02: httpd restarted
2005:04:01-08:54:20: httpd restarted
...

Also no entries in /var/log/directadmin/error.log or /log/directadmin/errortaskq.log with time close to reset start.

3rd server (FreeBSD 4.10):
from /var/log/cron
Code: 
...
Apr  1 00:30:00 delta /usr/sbin/cron[13951]: (root) CMD (echo 'action=tally&valu
e=all' >> /usr/local/directadmin/data/task.queue)
...
Apr  1 01:40:00 delta /usr/sbin/cron[20567]: (root) CMD (echo 'action=reset&valu
e=all' >> /usr/local/directadmin/data/task.queue)
...

whole /var/log/directadmin/system.log:
Code: 
2005:04:01-08:08:02: named reloaded
2005:04:01-10:09:00: httpd reloaded
2005:04:01-11:04:05: httpd restarted
2005:04:01-11:04:07: named reloaded
2005:04:01-11:11:01: httpd reloaded
2005:04:01-11:11:01: named reloaded
2005:04:01-11:35:00: httpd reloaded
2005:04:01-11:35:03: named reloaded
2005:04:01-11:36:00: httpd reloaded
2005:04:01-11:36:00: named reloaded
(Funny. It seems tally also "skipped" this night. Yep, in Webalizer stats - "Generated 30-Mar-2005 00:34 MSD")

whole /var/log/directadmin/errortaskq.log:
Code: 
2005:04:01-05:00:00: Unable to find cron id 1 in ./data/admin/backup_crons.list
2005:04:01-05:00:00: type=Unable to find that cron ID is an unknown type for the
 backup action

whole /var/log/directadmin/error.log:
Code: 
2005:04:01-03:01:28: The username hasn't been set.  Won't run the script without
 dropping privileges
2005:04:01-11:33:38: Socket write error: fd is connected to a pipe or socket who
se reading end is closed.  When this  happens the writing process will also rece
ive a SIG_PIPE signal.  (Thus, the write return value is seen only if  the progr
am catches, blocks or ignores this signal.)
2005:04:01-11:33:38: Error while sending ./data/skins/enhanced/images/nav-bg.gif
2005:04:01-11:33:40: bad sock
2005:04:01-11:33:45: bad sock
2005:04:01-11:33:46: bad sock

Can you reset the bandwidth by initiating the proper command from the command line?
Code: 
echo "action=reset&value=all" >> /usr/local/directadmin/data/task.queue
Click to expand...
Yes. But I though it's DA function to do that every month, isn't it?
 
Had it this month as well, just working on 1 server today, so I'm not sure about the rest...

Currently I've instructed a manual reset, let's hope this works...

Note to self (others that are interested): Never ever run the reset command at midday on a busy server :eek:
 
Yes. But I though it's DA function to do that every month, isn't it
Click to expand...
Partially, however DirectAdmin will not do anything unless it recieves the proper command, which is what the cronjob is supposed to issue so my guess is something is not working with your cron daemon or something along those lines.

DirectAdmin could probably create their own daemon to keep track of time and run the proper functions, but then that would probably take away some of the customizable functions (time-wise) that are available going through cron. (No need to reinvent the wheel was brought up previously, this is one place where that could apply)

I must have good luck since all the installations that I've done, it always seems to work properly. The only way to reproduce the problem is create a problem with cron.
 
ALL OTHER cronjobs works _without_ _any_ problems. So why you think it's cron problem? Then maybe it's because of our kernel/memory/cpu/bad_luck/etc...? ;)
 
I've found this issue on servers that have high load or not enough free memory.

On one of our systems we elected to upgrade the memory and that reduced the load (server does not need to swap as much) and then the quotas were reset without a problem.

Kind Regards,
Onno Vrijburg
 
Icheb said:
Had it this month as well, just working on 1 server today, so I'm not sure about the rest...

Currently I've instructed a manual reset, let's hope this works...

Note to self (others that are interested): Never ever run the reset command at midday on a busy server :eek:
Click to expand...

I have the same problem.. How did you do this reset?

Wijs
 
Log into your server using SSH

Type the following from the prompt ( NOTE the # signifies the prompt and is not to be included in what you type. )

# echo "action=reset&value=all" >> /usr/local/directadmin/data/task.queue

This should work within a minute or so.

Regards,
Onno
 
Same thing happend again, on the same server as last month. On other servers, there weren't any problems...
 
jmstacey said:
If the command I gave above works, then it narrows it down to a cron issue.
Click to expand...
It IS a cron issue, but all I ever did to the crons on that particular server is follow DA's guide to change the time they run to a bit more quite time at night (12 pm is NOT quite on that server, 3 am is).
 
Then are you sure there isn't a syntax error if cron itself is working fine?
That would be the most logical conclusion.
 
jmstacey said:
Giving us more information will help troubleshoot your problem ;)

Can you reset the bandwidth by initiating the proper command from the command line?
Code: 
echo "action=reset&value=all" >> /usr/local/directadmin/data/task.queue
Click to expand...


work fine :D
 
jmstacey said:
Then are you sure there isn't a syntax error if cron itself is working fine?
That would be the most logical conclusion.
Click to expand...
Yeah, cron was fine.
It looks like it did reset this month :), however I didn't really change anything. So it might be something like throwing up a coin...
 
Icheb said:
So it might be something like throwing up a coin...
Click to expand...
Exactly. I have tried many times to catch this bug. I tried to save copies of queue files just before dataskq run to check it's content later in case of error. But after i changed cron command to

dir=~/temp/`date +\%m\%d\%H\%M\%S`/; mkdir $dir; cp -p ~/da/data/task* $dir 2>/dev/null; /usr/local/directadmin/dataskq

daily tally newer skipped anymore.
After I reverted comman line back to

/usr/local/directadmin/dataskq

tally run was skipped again from time to time.

So now I suppose, it's skipped sometimes because of simutaneous run of dataskq and echo so sometimes echo writes command to queue at the same time (or a bit later?) as dataskq reads it and it's causes that written command skipped (I don't know why - it's just my supposition).

So I think if we change cron commands from

echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue

to something like

sleep 5; echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
sleep 5; echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue

That problem shouldn't appear anymore.

I'll test it on our servers.
 
ClayRabbit said:
(...)
So now I suppose, it's skipped sometimes because of simutaneous run of dataskq and echo so sometimes echo writes command to queue at the same time (or a bit later?) as dataskq reads it and it's causes that written command skipped (I don't know why - it's just my supposition).
[/B]
Click to expand...

it happens to me too (specially for stats gerenating, that happens every day)...
I also guess it's a concurrency problem while writing/[reading/deleting] the "DB"
I think some concurrency check should be done

thanks
 
You must log in or register to reply here.
Back
Top