-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 1/30/14, 10:34 AM, Mark H. Wood wrote: > On Wed, Jan 29, 2014 at 10:27:13AM -0500, Christopher Schultz > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Mark, >> >> On 1/29/14, 9:49 AM, Mark H. Wood wrote: >>> On Tue, Jan 28, 2014 at 12:32:22PM -0500, Daniel Mikusa wrote: >>>> On Jan 28, 2014, at 12:05 PM, Vye <v...@vye.me> wrote: >>>>> I have been unsuccessfully trying to remove the date from >>>>> catalina’s log file name. My ultimate goal is to logrotate >>>>> the file, which is best done when the file name is static. >>>> >>>> I’m curious, why are you trying to do this? The log files >>>> are being rotated out-of-the-box. They rotate by date, hence >>>> why the date is part of the name. Why do you need to rotate >>>> them with some other tool? What doesn’t work about the >>>> out-of-the-box configuration? >>> >>> I agree. logrotate is a very nice crutch for use when the >>> application doesn't rotate its own logs, but it is better to >>> use the application's rotation code when it exists, since the >>> application (with full knowledge of its internal state) can do >>> this more safely and efficiently than any external tool. >> >> I actually like logrotate's capabilities for maintaining a set of >> log files: rotate, compress, delete, script, etc. > > I agree that logrotate's set of features is quite nice. > >>> Cleaning up old log files is easily done with a simple cron >>> job, if the application does not trim old files. That >>> operation can be done just as well externally as internally. >> >> Sure, you can do this with scheduled scripts, but it logrotate >> is willing to do that work for you (e.g. easier commands, etc.) >> why not use it? > > logrotate works very well for logs created by short-lived > processes. No particular coordination is required, when the source > of the log starts, opens the file, writes a few records, and exits, > from time to time. > > Long-running processes require coordination, or else the new file > may sit empty for hours or days while the old file continues to > receive the log entries. logrotate and httpd work very well together, and httpd falls into the latter category. > logrotate has ways to handle this: > > o send the process a signal that causes it to close and reopen > logs. I don't think Tomcat has this. Correct. It's tough to receive signals in Java because it's such an OS-implementation detail. You can write native code to capture them, but ... eew. > jsvc does, and so (if you use jsvc to start Tomcat) you can use > this to rotate catalina.out. +1 > There's some good stuff about this at > http://wiki.apache.org/tomcat/FAQ/Logging#Q10 but it's for sysout, > not logging packages like JULI. I see some intriguing notes there > about logrotate's 'copytruncate' option, which I'll have to read > up on. With copytruncate, it is possible to lose data and end up with a few corrupted entries, so it's best used with it remains the only remaining option. > o run a command that somehow causes the process to close and > reopen logs. I don't think Tomcat has this. This kind of thing could be added: JMX can support arbitrary operations... an operation like "flushLogs" could be added that did just that. > o stop and restart the daemon, which forces a close/open of the > logs. It takes Tomcat several minutes to restart here, and while > I'm looking at ways to trim startup time, I really don't want to > bounce our services *at all* just to tidy the logs. Tomcat takes like 1 second to start itself up (which may be too long for you, granted). If your web application takes longer, then it's your web application's problem ;) > Thus I prefer to let Tomcat rotate its logs, since it can do that > without interfering with its operation, and to provide scripts to > handle trimming or archiving or other post-processing of the > closed logs. This is a reasonable conclusion, and I think it makes sense given the constraints of Java itself, the web application lifecycle, etc. > [just to be thorough] > > There are other options in some cases. > > o Apache HTTPD comes with 'rotatelogs', a filter that absorbs text > and writes it into files with a maximum size, maximum age, > date-stamped names, etc. If there's a way to connect log output to > a pipeline, a daemon that does not contain rotation logic can still > have rotated log files without restarting. Right. Tomcat does this by streaming logs to an outside process. Tomcat can't readily do this, but I think if you use a named pipe on the filesystem, it might be possible to do. > o Some syslog packages work well with logrotate (using the signal > mechanism), so if your daemon can log to syslog then the rotation > can be handled downstream. +1 syslog may be ugly, but it sure is good at its job. syslog can do things like aggregate logs from multiple servers into a single log elsewhere, etc. Plus there are tons of utilities that are built for watching syslog for various events, and you can leverage these things for monitoring, etc. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS6p2VAAoJEBzwKT+lPKRY0nAP/0OLN7SG6p42ughT3Azn5W/r bUD1eidca5O7exFK5QI6bP/BCwm8YycNhcuC6AbzBC1o2Hvh2VBgIVmua3s+GxzM tLCUccI+P0j3J693hsjf7xW/VJ0STQrwFrT3r2XhgDCytW6KADHtwtZq6HCXg6KT MMhjGdjvzc/X3dBUpE/hpLJDTKrN/d0wm7EKQrf4k/EiqktpukzCwdvmTqi2vNU/ C5fRmi+1Ns3pV/LhBs40yBfAJIcMsYvRUPs2w2sDeeKa/UM1VJQu+VTNazUa2qTP E6Wxrz2FYXfK0IrGskRwPj60LUbdN5Vd6/j8OsnQJu+5eHFiRCq9l1xa+pE8aJ/a JdQQ/i+RtIkvO5Q55Hwr+opx6gA0VN4RoDdg9g9fgsyKLtkcLDh3Qrlm7WcmvUtT 6rBs0voRRx3KoZ9afeSsUB4R448+/ohxDgRKEVqbwxcwr15ykzObGQAMNAqVAdPh qepEKUkuMBeEGvtKHpULlISq1mO7gakFr0VeEZigrnuSqPh2BLv2E6/XrLpISzbg IPjRNNPJnreoOxp6JoYzF2YgeRW2eqhlr/XRsekY3AREuvkgcqphgHI6vvbDl7+Y xbmlKm3I5FYadrJ7J9AnAhaPVZKFO0OteJdmGhyFTRsaPBLIriPKpvBoHthRtukc uveKWlSgJlrjCq5nKR3x =dUnG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
