Knowledgebase
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.
Check:
If you do see the above command in your cron log, then the next step is to check:
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:
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.
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.
Check:
/var/log/cron
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:
/var/log/directadmin/system.log
for the entry that looks something like this2009: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
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.