2 ms·

Almost completely unrelated to TFA: In the Apache Tomcat Systemd House of Horror story, we find this: > And let us mention another horror in catalina.sh: the

Almost completely unrelated to TFA: In the Apache Tomcat Systemd House of Horror story, we find this: > And let us mention another horror in catalina.sh: the logging. The dæmon process has its standard output and standard error redirected to a log file. This is a known-bad way to go about logging. One cannot size-cap the log file; one cannot rotate the log file; one cannot shrink the log file. It grows, as one file, forever until the dæmon is shut down. I was under the distinct impression that logrotate can handle cat-std*-to-file style logfiles: to rotate, copy the logfile, then truncate the original. Indeed, from logrotate(8): copytruncate Truncate the original log file to zero size in place after cre‐ ating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncat‐ ing it, so some logging data might be lost. When this option is used, the create option will have no effect, as the old log file stays in place. Why has the author never read the logrotate man page? :(

sveiss 11y ago
Doing that is inherently racey (as acknowledged in your man page quote), and you will lose some log data while the rotation happens if it's being written to quickly enough. If you need all your log data, you can't rotate or shrink it with this style of logging, hence 'known-bad'.
- simoncion 11y ago
  It is inherently racy. Noone is disputing that. But, remember that the author said: > One cannot size-cap the log file; one cannot rotate the log file; one cannot shrink the log file. It grows, as one file, forever until the dæmon is shut down. [0] Anyone with even the most basic understanding of how star-nix [1] systems handle files understands this to be an untrue statement. Take particular care to note that the author's statement was unqualified. If he had mentioned anywhere that you cannot do those things without some risk of data loss, there would be no controversy. Instead, he said -flat out- that rotating and size-capping a cat-std-whatever-to-log-file style log file is impossible. [0] http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/systemd-house-of-horror/tomcat.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/sys... [1] star-nix rather than $ASTERISKnix because I can't figure out how to escape a literal asterisk. :/

sveiss 11y ago

Doing that is inherently racey (as acknowledged in your man page quote), and you will lose some log data while the rotation happens if it's being written to quickly enough. If you need all your log data, you can't rotate or shrink it with this style of logging, hence 'known-bad'.

simoncion 11y ago
It is inherently racy. Noone is disputing that. But, remember that the author said: > One cannot size-cap the log file; one cannot rotate the log file; one cannot shrink the log file. It grows, as one file, forever until the dæmon is shut down. [0] Anyone with even the most basic understanding of how star-nix [1] systems handle files understands this to be an untrue statement. Take particular care to note that the author's statement was unqualified. If he had mentioned anywhere that you cannot do those things without some risk of data loss, there would be no controversy. Instead, he said -flat out- that rotating and size-capping a cat-std-whatever-to-log-file style log file is impossible. [0] http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/systemd-house-of-horror/tomcat.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/sys... [1] star-nix rather than $ASTERISKnix because I can't figure out how to escape a literal asterisk. :/