Hello,
Just an update, I've tracked one case down to an openlitespeed bandwidth bug, combined with a recent DA fix to read that bad data, which was previously not able to be read. For examples below, replace RESELLER with the name of the affected Reseller.
- If you're running openlitespeed, ensure it is updated to the latest version:
Code:
cd /usr/local/directadmin/custombuild
./build update
./build openlitespeed
- When a User is deleted, their used bandwidth is logged into that Reseller so it's still counted during the tally, even without the User:
Code:
/usr/local/directadmin/data/users/RESELLER/bandwidth.reseller.tally
- DA bug where there was no newline added to the end of that entry, so previous DA's count read the bad data, which was hiding the true OLS bw error.
- Recent DA fix is now able to read the lines that don't end in a newline, thus including the bogus data in the Reseller's bw count, exposing the issue.
So if think you're affected, check the bandwidth.reseller.tally file for the given Reseller.
If the very first number shows too high, just delete that line (it's a long line with a lot of encoded data).. or if you're unsure, delete the whole contents of the file, then recompute the tally for this Reseller
Code:
cd /usr/local/directadmin
echo 'action=bandwidthtally&value=RESELLER&type=reseller' >> data/task.queue; ./dataskq d432
where debug 432 is the tally debug level for a bit more info.
I've pushed some pre-release binaries which include extra debug output at this level (Compile time >= Oct 23 2019 at 10:56:28), where you'd be looking near the end for Tally::tallyReseller output, and the trace I found mentioned the call to getTallyTotal, which, in this case, is loading in the bandwidth.reseller.tally file.
If you're looking for a quick way to knock the bandwidth into a normal range:
Code:
cd /usr/local/directadmin
rm -f data/users/*/bandwidth.reseller.tally
echo 'action=bandwidthtally&value=all' >> data/task.queue; ./dataskq d432
as long as you're ok with not including bandwidth that belonged to deleted Users.
NOTE: It would also affect other webservers (apache/nginx/litespeed, etc) where the amount is smaller/correct, as the deleted User bandwidth wouldn't have showed up until the #3 fix from 1.53.0. In that scenario, the jump in bandwidth is actually correct, and was should have been shown in the past. Either way, please check the bandwidth.reseller.tally for the affected Reseller to see what's going on.
We've added a new row when an Admin is viewing a Reseller, such that you can now see how much of the total bandwidth is used by the deleted User bandwidth:
https://directadmin.com/features.php?id=2564 (pre-release binaries are now available)
I'll continue to step through the reported cases to see if there is any more information on this and will reply back once I know more.
Sorry for the inconvenience.
John