cPanel Broken Bandwidth Tracking

If you haven’t noticed yet on a lot of our servers specific accounts on each server do not have any bandwidth tracking what so ever.  If you’re on a shared hosting account you would only realize if your bandwidth usage has been zero.  For a reseller it’s highly likely at least one of your accounts is not tracking any bandwidth.  As it stands anyone affected by this is just being given a free ride as far as bandwidth and we’ll deal with any extra cost due to bandwidth usage not being available.  If you’re curious about the bandwidth usage of a specific site you can still retrieve this via web statistics like awstats or webalizer.  This post though is to actually talk about why it’s happening and what steps we’ve attempted to get it resolved.

We have strong reason to believe this started around 2010-02-19 or around then when we updated our cPanel servers to release build 43472.  This build addressed the following problem:

Updated bandwidth algorithms to address an issue calculating the bandwidth total for accounts with high traffic sub domains.

This was a pretty big deal as some users were experiencing this.  We figured an easy quick fix by cPanel no problem we’ll have everyone with proper bandwidth usage again.  It did resolve over calculation of bandwidth for high traffic sub domains it just messed up bandwidth tracking in general for a lot of accounts.

We discovered this problem in early March and to our surprise found a post on the cPanel forums with lots of other users complaining about it: http://forums.cpanel.net/f5/bandwidth-not-calculating-149637.html There was a similar topic when bandwidth was over calculating and a cPanel representative was quick to respond saying they’re working on a fix.  This topic though started March 1st and now into the second page has not received any response from cPanel themselves confirming there is an issue.  Typically with cases like that they would respond back saying yes we’re working on it.

Based on the lack of response from cPanel to the topic itself I gave them the benefit of the doubt and decided to make a support ticket which I tend to avoid doing.  The ticket was opened on March 22nd and eventually on March 23rd they said our issue was load average.  Of course this being an insane excuse for a small percentage of accounts to have broken bandwidth usage.  I said fine we’ll let stats run with a higher load average and see what happens.  I gave it 24 hours and no surprise as I told them at the time it would not solve the problem and we still have sites without bandwidth usage unless we force ran it via /scripts/runweblogs which processes web stats as well as updates a users bandwidth usage.  Typically cPanel does this for you a few times a day for the bandwidth usage which it was not doing.

We had now been passed off to a level3 technician at cPanel suggesting yet another miracle fix late March 23rd.  The fix was the following:

/scripts/autorepair repair_bwsummary
/usr/local/cpanel/bin/repair_bwsummary
/usr/local/cpanel/bin/repair_bwsummary brokenusername

I had some hope for this fix as it was using an autorepair script from cPanel.  We ran the same command across a few servers and their affected users.  We gave it 24 hours to see if bandwidth usage was tracked over that 24 hour period.  Unfortunately it was not the case and once again back to cPanel asking for help.  This time we were told development has been informed and they’d get back to us most likely Monday since it was Friday night already. To our surprise development was a little quicker and the level3 technician helping us said the developer working on the issue had a manual patch fix that may work.  They offered to apply it to the servers at which point we declined.  The reason being we have a lot of servers and having cPanel attempting to repair all these users seemed to not be a wise solution.  This especially true when there was no guarantee and there was an official fix being worked on that would be passed through quality assurance then released.  This news came on March 24th and it’s now and it’s been over a week without this officially being pushed out to all cPanel builds as far as I can tell.

I was surprised at the time people were not complaining more so but then recently topics have started to show up on webhostingtalk as well.  This topic http://www.webhostingtalk.com/showthread.php?t=936718 outlines web hosts seeing this and a some opening tickets.  Assuming they’re telling the truth about the tickets cPanel is being slow to admit there is even an issue.

So unfortunately for us we’re going to continue to deal with this problem.  A fix being anywhere in sight?  I doubt it at this point based on how long this has been and the fact you cannot get a response on their forums about it and their support people are taking a long time to admit there is even a problem.  If I was big on conspiracies I’d say it’s some big provider paying cPanel to do this as this provider is probably unlimited bandwidth.  So broken stats for them is not bad but for other hosts it’s a costly matter when they bill for bandwidth.  Although that’s highly unlikely and the more likely cause is just part of the steady decline of the cPanel product.  This is not just my opinion either as far as decline people have been disappointed in the quality of releases as of late with bugs and other problems.  Bug fixes to issues have been slow and simple usability enhancements to make certain sections of the panel as friendly as others have been ignored for years.  Even usability features added in one release have been then removed in newer versions with forum posts and tickets be ignored.  I suppose we should have all seen this coming with the removal of their bug tracker and being forced to file bug reports via ticket and features now having to be requested via forum.  Granted they were not maintaining the bug tracker but maybe they should have done that so they could construct roadmaps of bug fixes and features they were adding as that is typically what’s done.

This entry was posted in General. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *