Open Stack

Systemd logs all python output by default, if you have rsyslog to pull from the systemd as well you can get double logging.  I think you need to execute under systemd with:  StandardOutput=null in the unit file under the [service] heading.  Atleast that’s what we do.

Disclaimer: we don’t run rsyslog but use file output (and we are running CentOS7).  Our problem was that we got debug level messages to /var/log/messages and the correct loglevel in /var/log/nova/nova-compute.log Telling system to not ouput logs prevented that from happening.

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Gustavo Randich <gustavo.randich at gmail.com>
Date: Tuesday, August 9, 2016 at 3:52 PM
To: "openstack-operators at lists.openstack.org" <openstack-operators at lists.openstack.org>
Subject: [Openstack-operators] systemd and duplicate logs -- /var/log/syslog and /var/log/nova/nova-compute.log

Hi guys,

We want to be able to forward nova-compute's log to a central rsyslog but at the same time mantain the local "/var/log/nova/nova-compute.log". In Icehouse we achieved this with the following configuration in "/etc/rsyslog.d/60-nova.conf":

*.*;local0.none,auth,authpriv.none   -/var/log/syslog
local0.*                 @@10.161.0.1:1024<http://10.161.0.1:1024>
local0.*                 /var/log/nova/nova-compute.log

We also had to comment this line in "/etc/rsyslog.d/50-default.conf" (reference: https://www.osso.nl/blog/rsyslog-cron-deleting-rules)

*.*;auth,authpriv.none   -/var/log/syslog


Now, in Mitaka / Ubuntu 16 / systemd, with this same configuration, we are getting duplicate logs: every line goes to /var/log/syslog and /var/log/nova/nova-compute.log

We want to only log in nova-compute.log

Maybe this is because systemd is forwarding everything to rsyslog? By default, /etc/systemd/journald.conf has "ForwardToSyslog=yes"

thanks!
Gustavo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160809/5b901e18/attachment-0001.html>