The situation: Our logfiles get rather large, and we do the processing locally (rather than using the server-based AWStats, etc). So our stats are set up for daily archiving; we then download that day's compressed file and delete it from the server.
The compressed archive for a given day would be labelled as "mydomain.ext-thismonth-thisyear.gz". We have been doing this daily compression, download, and deletion process for years, and the naming protocol has always been the same. But since the "rndc" update, the compressed archives have been mis-named as "mydomain.ext-LASTMONTH-thisyear.gz".
I contacted my web host's Support about this mis-naming problem. The techs couldn't figure it out, so they contacted cPanel Support, and did whatever they were instructed. However, this "fix" does not appear to have changed anything. And nobody here seems to have encountered this particular issue.
So far, in attempts to fix the issue myself, I have tweaked the file /usr/local/cpanel/cpanellogd as follows: In lines 2287 and 2297, I have changed the gzip command variable from "$lastmonth" to "txtmonth". In lines 69-71, I have changed the month numbering from 0-11 to 1-12.
These changes have had no apparent effect: While the server logs themselves continute to contain the correctly-dated information, the daily archives are still being labelled with the name of whatever last month was.
The request: Is there some other script that might be running the compression process, or at least the naming part of the process? Is there some other line in the above-referenced file that I should edit?
Thank you.
Eliz.
The compressed archive for a given day would be labelled as "mydomain.ext-thismonth-thisyear.gz". We have been doing this daily compression, download, and deletion process for years, and the naming protocol has always been the same. But since the "rndc" update, the compressed archives have been mis-named as "mydomain.ext-LASTMONTH-thisyear.gz".
I contacted my web host's Support about this mis-naming problem. The techs couldn't figure it out, so they contacted cPanel Support, and did whatever they were instructed. However, this "fix" does not appear to have changed anything. And nobody here seems to have encountered this particular issue.
So far, in attempts to fix the issue myself, I have tweaked the file /usr/local/cpanel/cpanellogd as follows: In lines 2287 and 2297, I have changed the gzip command variable from "$lastmonth" to "txtmonth". In lines 69-71, I have changed the month numbering from 0-11 to 1-12.
These changes have had no apparent effect: While the server logs themselves continute to contain the correctly-dated information, the daily archives are still being labelled with the name of whatever last month was.
The request: Is there some other script that might be running the compression process, or at least the naming part of the process? Is there some other line in the above-referenced file that I should edit?
Thank you.
Eliz.
