Description of problem: From the config files for Swift as deployed in RDO: account-server.conf:log_facility = LOG_LOCAL2 container-server.conf:log_facility = LOG_LOCAL2 object-server.conf:log_facility = LOG_LOCAL2 Should we be logging Swift to /var/log/messages vs. having a separate set of logs in /var/log/swift like all of the other services?
I should note that original Swift used to contain stubs to log into /var/log/swift.log, but they bitrotted. The log rotation is the main problem.
(In reply to Pete Zaitcev from comment #1) > I should note that original Swift used to contain stubs to log into > /var/log/swift.log, but they bitrotted. The log rotation is the > main problem. Why is swift different in this respect? logrotate should be configured for the logs of all the services in the same way.
As it turned out, I forgot where the main difficulty was. The problem is how to modify rsyslog.conf. I propose to punt it over to docs.
Created attachment 809633 [details] Candidate 0
Lon offered a suggestion: modify Swift to log local2.debug. This way the messages won't end in /var/log/messages with the stock rsyslog.conf, but we can log them in /var/log/swift/swift.log.
The problem with Lon's suggestion is that the configuration log_level does not change at what level Swift logs. It only changes what the threshold or muting is (done with logger.setLevel()). Thus, to make logger.info() to log at syslog level "debug" requires a special shim that effects such. It's not impossible, but violates the principle of least surprise. A quick sed string would be: sed -e "s/cron.none[ \t]*\/var\/log\/messages/cron.none;local0.none\t\/var\/log\/messages/" -i- /etc/rsyslog.conf
Created attachment 899821 [details] Candidate 1
(In reply to Pete Zaitcev from comment #7) I'm maintaining rsyslog and let me start by saying that our default setup for allowing applications to automatically drop in rsyslog configuration is suboptimal. I've been thinking about it lately and don't have any elegant solution so far. What we have now is certainly not it. > Candidate 1 swift.conf: local0.*;local2.* /var/log/swift/swift.log & ~ I've skimmed through the suggested configuration. Lets imagine this hypothetical scenario: The file name would be ordered pretty far lexicographically. Suppose a similar app provides a conf file /etc/rsyslog.d/slug.conf containing: local0.* /var/log/slug/slug.log This looks fairly benign; it doesn't delete the logs, so swift won't be affected. But since "slug" is ordered before "swift" and thus processed first, the slug.log would contain all the "slug" logs including all "swift" logs, breaking your use case of isolating the "swift" logs. This isn't a very surprising outcome, but I hope it illustrates how hard it is to actually achieve what you wanted. Another point is that using localN as the filter isn't advisable. There are only eight of such facilities and the chance of collision is high. If you feel you must filter anyway, use a syslog tag (application name) for it. Or even better something unique(-ier). I'm thinking about restructuring the configuration to better support such usecases, but at the moment, my advice would be: If you don't want to log to /var/log/messages and don't have non-syslog way of logging to a file, turn logging off and instruct the user to turn it on manually. Or, if you really, really need to automatically drop in cfg, try to minimize the potential harm. Erasing local0 and local2 is not it.
See also bug 1154947.