
This will work out to about 30 or 31 files (if the month is already past), or however many days have past in the current month. Get the Apache logs for the month.įirst step is to get all of the logs for each domain for the month. So, if the missing dates are in June, and it is currently August, you’ll need to remove the data files for June, July, and August (they look like this where MM is the two digit month and YYYY is the four digit year) to a temporary directory so they are out of the way. So we’ll need to move the more recent month’s stats to a temporary location out of the way.

Awstats not updating update#
Move the data files of newer monthsĪWStats can’t run the update on older months if there are more recent months located in the data directory. Looks like I need to write a script… Step 1. This means I’ll have to do this process about 140 times. We have our Apache logs rotate each day for each domain on the server (or sub-directory that is calculated separately). Here’s how I have Apache set up, and the process I went through to get the missing days back into AWStats. Replace the AWStats data files for the following months (undo step 1).Īgain, depending on how you have Apache logs set up, this can be an intensive process.Run the AWStats update tool, using AWStat’s logresolvemerge tool and other changed paramaters, to re-create the AWStats data file for that month.Copy the Apache logs with all of the stats for the month with the missing days to a temporary directory.Move the AWStats data files for months newer to a temporary directory.The AWStats Documentation (see FAQ-COM350 and FAQ-COM360) has some basic steps to fix the issue, outlined below: Unfortunately, it’s a bit labor intensive, and depends on how you rotate your apache logs (if at all, which you should). I didn’t notice this until several days later, leading to a large gap in the stats for April.

Cron is the absolutely necessary tool for getting the server to run things on a timed schedule.
Awstats not updating software#
I reinstalled some software on our AWStats machine, and forgot to reinstall cron. Usually, as in my case, it’s because I messed up. Then, AWStats continues its work (if configured as cron job) and updates the statistics from the formerly offending point on.Sometimes AWStats will miss some days in calculating stats for your site, and that leaves a big hole in your records. Before you should stop the webserver (e.g., service apache2 stop) and afterwards start it again ( service apache2 start). However, if more than 50 of that kind happen to occur without a break, AWStats stops working completely from this point on and for the future (exactly: until the log file is exchanged).Īs a remedy, one can delete the lines in question from the log file (at least so many that less that 50 remain consecutively). Such entries are appearing from time to time in webserver log files and are no problem normally. (where stands for a concrete IP address) as invalid. "-" 408 1447 "-" "-"Īpparently, AWStats evaluates log-file entries with blank fields as
Awstats not updating windows#
"GET / HTTP/1.1" 200 1234 "" "Mozilla/4.0 (compatible MSIE 5.01 Windows NT 5.0)"Īnd this is an example of records AWStats found in your log file (the record number 50 in your log): This means each line in your web server log file need to have "combined log format" like this:

Your log file /var/log/apache2/ssl_access.log must have a bad format or LogFormat parameter setup does not match this format. Where stands for the configuration in question, results in an error message likeĪWStats did not find any valid log lines that match your LogFormat parameter, in the 50th first non commented lines read of your log.

The following situation arises (for me the first time after years of usage): AWStats runs by crontab, but all of a sudden no statistics are generated anymore an error related to the execution of crontab can be ruled out.
