Add to Favourites Add to Favourites    Print this Article Print this Article

My monthly bandwidth is not resetting.

The monthly bandwidth reset is done at 4:20am on the first day of the month.
If you find that this did not happen (allow about hour for the dataskq to run, pending number of sites) then there a few steps you can do to find out why, and reset it manually.

The first thing to check is the cron logs to ensure that the reset was actually issued.


for the 4:20am timestamp for the 1st day of the month.  You sould see something like:

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

If you don't see that command, then you'll want to check this guide to ensure that your crond is running and the /etc/cron.d/directadmin_cron file is working correctly.

If you do see the above command in your cron log, then the next step is to check:


for the entry that looks something like this

2009:04:01-04:20:01: Reset all command Received

if you don't see that code, then you'd again want to use the same guide as above to debug the issue.

If you do see the above log entry, then scroll just below it to confirm that each user is mentioned. If not, then likely the users are not all set in the users.list file.  You can use this guide to reset all users.list files.

At this stage, hopefully you'd have figured out why the reset didn't happen, and have fixed it so it does happen next time.  However, the reset still wouldn't have happend for the past reset.  So to do that, you'd use the cleanreset task.queue command.  Type:

echo "action=cleanreset&value=all" >> /usr/local/directadmin/data/task.queue
/usr/local/directadmin/dataskq d
echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

which should reset things from the start of the month without losing data.   Manaully doing the regular reset mid-month will lose current data that you still want, hence we use the cleanreset which scans all datestamps to ensure it doesn't delete anything it shouldn't.

If you didn't figure out why the reset didn't happen, you may also want to check for other competing tasks.  For example, if the server is rebooted at the time of the reset, that could prevent it from working.  Also, the dataskq is also used by other tasks such as backups, so check to see if you've got any large backups running near the same time as the reset, and check /var/log/directadmin/errortaskq.log for any errors relating to them.

Was this answer helpful?

Also Read