![]() ![]() Make sure that the directive “AllowToUpdateStatsFromBrowser” is set to 1. Check directive permission of .conf file by using the below command. Note: Do not forget to change the user with your custom cPanel username. Navigate to the awstats directory using the below command.Log in to SSH using the root credentials.Note: SSH with the root access is mandatory to perform this task. Fix AWStats Not Updating Issue Via SSHįollow the below steps to diagnose and fix AWStats not updating issues in cPanel. Otherwise, you can use the WHM method to solve this issue as the WHM user-friendly interface will help you solve this error more efficiently. If you’re familiar with Basic Linux Commands, then it’s recommended to use the SSH method to solve AWStats not updating error. Well, it’s easy to solve AWStatus not updating issue from SSH and WHM. However, we can fix this error manually by diagnosing several things in WHM and SSH. But, sometimes it displays the “AWStats not updating automatically” which is quite irritating. It provides easy-to-understand graphical representations to the users so they can analyze the website deeply & effortlessly. What is AWStats?Īdvanced Web Statistics (AWStats) is a free & powerful log analyzer tool to create advanced statistics reports for FTP, mail, and streaming server. However, before starting ahead, let’s have a brief look at AWStats. So, let’s have a detailed discussion to solve the AWStats not updating issues in cPanel. Usually, this error occurs due to wrong file permissions, configuration errors, wrong directives, etc. Correcting those three entries, enabling the cron job, and manually generating the first report fixed the problems.There are several reasons behind AWStats not updating error.The correct path entry should be LogFile=/var/log/virtualmin/_access_log.On the other hand, it would have generated historical data for as far back as the logs went. Actually, the LogFile path probably would have worked, but have been much slower because it would have had to parse the log for the entire domain.The problems were that the LogFile path, SiteDomain, and HostAliases entries were incorrectly generated.After conversion to subservers, Awstats failed on every initial attempt to enable, on every subserver and the parent server.More about that will be forthcoming in a related thread. AWstats couldn’t be enabled on the subdomains until they were converted to subservers.cPanel changed things around multiple times during that period, implementing kludges galore to hold things together.The site had been on cPanel servers since its inception.It’s had relatively few updates to the core code except for those needed for MySQL compatibility.The site was converted from a static HTML site to a PHP site in 2005.Some observations, some (or all) of which may be specific to my case. I corrected the path and manually executed the job, and voila, it worked.Īt that point I scheduled the cron job to run daily. I corrected those two settings and went to Webmin > Servers AWstats Reporting, where I noticed that the path was wrong and and the job wasn’t scheduled. That was also true before I did the above steps, and those entries in the config file for the parent domain may well be what caused enabling AWstats on the sub to fail. Re-enabling AWstats for the sub resulted in a .conffile with errors: SiteDomain = "localhost.localdomain" ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |