AWStats not working this month

[Wassercrats]

The stats software that Futurequest provides works, but AWStats shows all zeros for April. This is the first time this month that I checked it. Am I the only one? I took a look in my AWStats directory and none of the file names start with 04 and end with 06, if that means anything. Not sure what to do. I'll figure out something later if nobody has any tips.

[Wassercrats]

All zeros since March 14th and it won't update. Guess I'll try installing it again when I get a chance.

In the documentation, it mentioned running awstats_configure.pl, but I didn't see that mentioned in the installation instructions on this forum, so I guess I won't try it.

[Bob]

Are you trying to update them via the "Update Now" via browser?

At some point many of us have experienced issues with browser updates due to the size of the stats, processing time, and have to resort to Command Line updating, cron works well to keep them updated usually...

-Bob

[Wassercrats]

Yeah, with whatever that button is called on top of the stats page. But I don't get heavy traffic. I have logs back to Nov. 2001, when I began hosting with Futurequest, but I only have stats back to Oct. 2004 in cgi-bin/AWStats. I'll look into the command line thing.

[Wassercrats]

So, here's what happened when I tried the command line:[userone@FQ-Rasmus:/big/dom/xpolisource ]$ cgi-bin/AWStats/awstats_updateall.pl ----- awstats_updateall 1.0 (build 1.10) (c) Laurent Destailleur -----
awstats_updateall launches update process for all AWStats config files (except
awstats.model.conf) found in a particular directory, so you can easily setup a
cron/scheduler job. The scanned directory is by default /etc/awstats.

Usage: awstats_updateall.pl now [options]

Where options are:
-awstatsprog=pathtoawstatspl
-configdir=directorytoscan
-excludeconf=conftoexclude (Note: awstats.model.conf is always excluded)And I still don't see my stats. The update now link leads to http://www.polisource.com/cgi-bin/AWStats/awstats.pl?framename=mainright&update=1. I don't feel like looking in awstats.pl to see exactly what it does.

...I'll try the "now" command...

[Wassercrats]

No, typing "now" didn't work, and adding it after the file name, like "-now" didn't work. I won't even bother installing it again.

[Bob]

The command I use, with your domain substituted...

/big/dom/xpolisource/cgi-bin/awstats.pl -config=www.polisource.com -update

Path to actual awstats.pl the name of the domain is all that is in mine, IIRC...

Edit: Actually that is the command line in my cron, when I was running it to auto run Awstats daily, don't want to mislead anyone... :blah: Can't find the actual CLI command right off the bat...

-Bob

[Wassercrats]

That worked at the command line, but I don't want a cronjob that might update my stats hours before I look at them. I also don't want to log into the command line to update them and then to AWStats to view them. Maybe I'll add a feature to AWStats that creates a cronjob that's executed immediately and updates my stats. Maybe I'll even make AWStats refresh the screen when the cronjob is finished so the correct "Last Update" date is shown and I'll know it's done. Or maybe I'll try Google Analytics instead.

[Bob]

It is also possible that if you check them daily and update them that the Browser based "Update" will work for you, on a daily basis, as the processing would not take near as long... Just a thought.

-Bob

[Wassercrats]

Yeah, that link works now. I don't remember needing the command line when I first installed AWStats, when it would have needed to work even harder, but I'm not sure. I documented my initial installation it in some posts, but it's not worth looking it up. The load average for Rasmus seems to be higher than it was late last year. Over 1, late nights. Maybe it was better in the old days.

Now that I think of it, that probably wouldn't increase Futurequest timeouts. Only if AWStats times out based on clock time would it matter.

[Bob]

Generally on initial install there is a command line initial build stats, at least again as far as i can remember.

However the issue would be with the processing time which would be hugely different for a number of days of stats versus one or less. Stats processing is a major processing load and we have seen issues with AWstats exceeding the processing memory or time limits needed to protect the servers when in a shared environment.

Glad you got them updated in any event,
bob