On 5/17/05, Paul Howarth <paul@xxxxxxxxxxxx> wrote: > Bob Brennan wrote: > > I host some relatively steady volume virtual domains and in order to > > keep the log access files to a reasonable size I logrotate them once > > every night and only keep 10 days worth. The logrotate works fine with > > typically > > access_log > > access_log.1 > > access_log.2 > > .3 .4 .5 etc > > happening as expected, the problem is that only one of those files > > receives the log information, even as it's name changes! So typically > > access_log.1, .2, .3 for instance are all 0b while .4 continues to > > grow into the megabytes until it is deleted. > > > > Before blaming it on my configuration twiddles or virtual sites let me > > note that I have an up2dated FC3 server install and in /var/log I note > > that logs files I have never done anything with, such as up2date, > > xferlog, and spooler exhibit the same problem whereas boot.log, cron, > > maillog, and messages all have sequential and full files with the .1 > > .2 .3 extensions, behaving as I would expect. These files all have > > default FC3 logrotates. > > > > As test I renamed a troublesome "access_log.3" to "rubbish" and > > accessed the site, the access was logged to "rubbish" while a file > > called "access_log" in the same directory stays at 0b. > > > > Obviously a feature I don't know about is tracking the file being > > written to even though it's been renamed. I doubt it's a lock problem > > because more than half the log files exhibit it all the time and few > > are updated frequently enough to cause a race condition, but I'm open > > to suggestions. > > > > Any help/pointers/ideas greatly appreciated, I can't even think what to google. > > The log file that you renamed is still open (by the server) and so it is > still able to write to it (it's accessed by a file handle rather than by > a name, once it's been opened in the first place). > > You need to get the server to close the log file and reopen it (which > will access the new file). This is usually done by using a "postrotate" > script in logrotate that sends an appropriate signal to the server. For > example, in the standard FC3 httpd logrotate file, there is: > > postrotate > /bin/kill -USR1 `cat /var/run/httpd.pid 2>/dev/null` 2> > /dev/null || /bin/true > endscript Thanks Paul - looking in my own logrotate file for httpd I find: "/bin/kill -USR1 `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true" as the postrotate command, nearly the same as your line except for the /bin/true part. I will put that postrotate command into my less critical site's logrotate files and see what happens over the next few days, then put it into all logrotates that exhibit the problem. Live and learn! Thanks again for the quick response, bob
