The following will log twice on rhel6, and once in f20/rhel7. This seems to be somehow a libc/syslog bug.

#include <syslog.h>

void main() {
    openlog("spice-vdagent", LOG_PID, LOG_USER);
    syslog(LOG_ERR, "foo");
}

reassigning to rsyslog for more investigation.

(In reply to Marc-Andre Lureau from comment #1)
> The following will log twice on rhel6, and once in f20/rhel7. This seems to
> be somehow a libc/syslog bug.

Log twice to where? I don't see it on my el6 with rsyslog-5.8.10-8.el6.x86_64.

Could you post your rsyslog version? Have you done any changes to /etc/rsyslog.conf? Are there any files in /etc/rsyslog.d?

(In reply to Swapna Krishnan from comment #0)
> Description of problem:
> I built spice-vdagent from upstream on RHEL 6.6. spice-vdagent logs the same
> line twice to /var/log/spice-vdagent.log

The /var/log/spice-vdagent.log file is not handled by rsyslog - unless one of the packages dropped a configuration file into /etc/rsyslog.d. Thus this probably has nothing to do with rsyslog.

You can loop up what is writing to /var/log/spice-vdagent.log with "fuser -v /var/log/spice-vdagent.log".

(In reply to Tomas Heinrich from comment #3)
> Log twice to where? I don't see it on my el6 with
> rsyslog-5.8.10-8.el6.x86_64.
> 
> Could you post your rsyslog version? Have you done any changes to

same version

> /etc/rsyslog.conf? Are there any files in /etc/rsyslog.d?


Yes, I didn't realize before.

The spice-vdagent.spec says:
# RHEL-6 has no /etc/rsyslog.d

so /etc/rsyslog.conf is modified with this appended:

# A template to for higher precision timestamps + severity logging
$template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"

:programname, startswith, "spice-vdagent"	/var/log/spice-vdagent.log;SpiceTmpl

And I have /etc/rsyslog.d/spice-vdagentd.conf as well, probably because I did "make install" manually.

So closing this bug

> And I have /etc/rsyslog.d/spice-vdagentd.conf as well, probably because I
> did "make install" manually.
> 
> So closing this bug

Sorry, I submitted a bit too quickly. So, the rhel package doesn't create /etc/rsyslog.d/spice-vdagentd.conf. It was added manually, so it is user fault.

Removing /etc/rsyslog.d/spice-vdagentd.conf solves the issue.

The RHEL7 package installs /etc/rsyslog.d/spice-vdagentd.conf , I suspect it will be possible to get in the situation you describe on VM upgrades:
- user installs the RHEL6 package, rsyslogd.conf is modified to add the spice-vdagent snippet
- user upgrades to RHEL7, rsyslogd.conf most likely stays unchanged, and the package installs /etc/rsyslog.d/spice-vdagentd.conf

(In reply to Christophe Fergeau from comment #7)
> The RHEL7 package installs /etc/rsyslog.d/spice-vdagentd.conf , I suspect it
> will be possible to get in the situation you describe on VM upgrades:
> - user installs the RHEL6 package, rsyslogd.conf is modified to add the
> spice-vdagent snippet
> - user upgrades to RHEL7, rsyslogd.conf most likely stays unchanged, and the
> package installs /etc/rsyslog.d/spice-vdagentd.conf

that's very likely. Is it supported rhel6->rhel7 upgrade? Any idea how to handle that?

Yes, rhel6->rhel7 upgrades are supposed to be supported.

rhel6 seems to have /etc/rsyslog.d these days, so one first step could be to stop patching rsyslogd.conf and always install a file in rsyslog.d.

We could try to remove automatically what we added to rsyslod.conf on upgrades, but we have to be careful there as the file might have been user-modified, and we need to make sure we don't break it.
Another option may be to not install the file in rsyslog.d when we are doing an upgrade, but I don't know how easy it is to do.

(In reply to Christophe Fergeau from comment #9)
> Yes, rhel6->rhel7 upgrades are supposed to be supported.
> 
> rhel6 seems to have /etc/rsyslog.d these days, so one first step could be to
> stop patching rsyslogd.conf and always install a file in rsyslog.d.

Well, that would be pushing the problem in even more common cases.

> We could try to remove automatically what we added to rsyslod.conf on
> upgrades, but we have to be careful there as the file might have been
> user-modified, and we need to make sure we don't break it.

Yes, difficult option imho.

> Another option may be to not install the file in rsyslog.d when we are doing
> an upgrade, but I don't know how easy it is to do.

I don't know how rsyslog work, it would be nice if there would be a way to avoid duplication of rules.

I guess the easier in rhel7 is to not install (remove in update) the rsyslog.d file, and keep the .conf rule we have instead...

Also, it's not that useful to have clear text seperate syslog files for vdagent, we could probably remove that rsyslog config, and use journalctl SYSLOG_IDENTIFIER=spice-vdagent  SYSLOG_IDENTIFIER=spice-vdagentd

I would go for the last option and I sent a patch to remove rsyslog config files from upstream to prevent this problem from happening when installing from tarball (what happened to me and swapna probably):
http://lists.freedesktop.org/archives/spice-devel/2014-September/017355.html

(In reply to Marc-Andre Lureau from comment #10)
> I guess the easier in rhel7 is to not install (remove in update) the
> rsyslog.d file, and keep the .conf rule we have instead...

This sounds like a step backward...
Something ugly that should work would be to grep the .conf file for the vdagent stuff that used to be added there, and to remove the rsyslog.d file when it is present.

> 
> Also, it's not that useful to have clear text seperate syslog files for
> vdagent, we could probably remove that rsyslog config, and use journalctl
> SYSLOG_IDENTIFIER=spice-vdagent  SYSLOG_IDENTIFIER=spice-vdagentd

I don't know if there are some rules as to when to rely on journalctl and when to use rsyslog, but this makes sense.

Patch from comment #10 is upstream now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0359.html