Bug 809916

Could you provide the outputs of "systemctl status syslog.service"
and "systemctl status syslog-ng.service" please?

As requested:

"systemctl status syslog.service"
syslog-ng.service - System Logging Service
          Loaded: loaded (/usr/lib/systemd/system/syslog-ng.service; enabled)
          Active: active (running) since Sun, 2013-03-17 00:32:01 CET; 3 days ago
         Process: 1335 ExecStartPre=/usr/sbin/syslog-ng-service-prepare (code=exited, status=0/SUCCESS)
        Main PID: 1341 (syslog-ng)
          CGroup: name=systemd:/system/syslog-ng.service
                  â 1341 /usr/sbin/syslog-ng -F
---------------------------------------------

systemctl status syslog-ng.service
syslog-ng.service - System Logging Service
          Loaded: loaded (/usr/lib/systemd/system/syslog-ng.service; enabled)
          Active: active (running) since Sun, 2013-03-17 00:32:01 CET; 3 days ago
         Process: 1335 ExecStartPre=/usr/sbin/syslog-ng-service-prepare (code=exited, status=0/SUCCESS)
        Main PID: 1341 (syslog-ng)
          CGroup: name=systemd:/system/syslog-ng.service
                  â 1341 /usr/sbin/syslog-ng -F
---------------------------------------------

I have also seen it once, but at that time I could not figure out how to reproduce it.

Basically, the syslog-ng start is requested by each log message via
syslog.socket dependency. Did you increased the systemd log level,
so it logs each of these attempts?

But finally, syslog-ng should be able to suppress them. The default
config contains suppress(30) for /var/log/messages:

destination messages { file("/var/log/messages" suppress(30) owner(-1) group(-1) perm(-1)); };

Does your config contain it, could you attach /etc/syslog-ng/syslog-ng.conf
please?

Created attachment 530586 [details]
syslog-ng.conf

No, I didn't change systemd log level - btw. didn't know that this is possible.

Yes, I know that "suppress(30)" should reduce the number of messages, and checked it before opening the bugzilla entry. But
a) suppressing them is not the solution
b) suppress(30) is enabled and doesn't work.

Yes, I have a modified syslog-ng.conf file, but there are no changes, which are related here. 

But for sake of completeness, I've attached my modified syslog-ng.conf - see above

(In reply to comment #6)
> No, I didn't change systemd log level - btw. didn't know that this is
> possible.

OK, then I don't need to ask if you changed the
  /etc/systemd/{system.conf,journald.conf}
somehow or set some systemd.* boot parameters (cat /proc/cmdline)? ;-)

> Yes, I know that "suppress(30)" should reduce the number of messages, and
> checked it before opening the bugzilla entry. But
> a) suppressing them is not the solution

Not? I fear it is the only solution available.

Except of fixing the program that generates the message to not log
same message again and again -> something for "osc bugowner systemd"
in this case, not for "osc bugowner syslog-ng".

> b) suppress(30) is enabled and doesn't work.

Not? On my host the suppression generally works:

# grep suppress /var/log/messages

shows me message lines like:

systemd: Last message 'Deactivating swap /d' repeated 2 times, suppressed by syslog-ng

# for i in {1..30} ; do logger baaaaaaaaarrrrrrrr ; done
# logger flood end
# grep baaa /var/log/messages
...: baaaaaaaaarrrrrrrr
...: Last message 'baaaaaaaaarrrrrrrr' repeated 29 times, suppressed by syslog-ng on ...

> Yes, I have a modified syslog-ng.conf file, but there are no changes,
> which are related here. 
> 
> But for sake of completeness, I've attached my modified syslog-ng.conf
> - see above

Yes... your config looks fine and contains the suppress option for
/var/log/messages.

In your message there is also no "[ xxx.yyyyyyyy]" kernel like monotonic
clock timestamp in the front of the message which could make them look
unique ... right?

OK, IMO I've verified that syslog-ng suppression works fine and there
seems to be no misconfiguration causing it on syslog-ng side.

Reassign to systemd maintainer - Frederic, any Idea?
Either there is come config option set somehow or systemd tends to flood
here logging a message while every of the 1100 checks if syslog daemon is
already or not; it should do things like this only in debug mode IMO.

> if you changed the
>   /etc/systemd/{system.conf,journald.conf}
> somehow or set some systemd.* boot parameters (cat /proc/cmdline)?

No change made.

> Not? I fear it is the only solution available.

This is only fixing the symptoms not the cause.

> Not? On my host the suppression generally works:

sorry, for misunderstanding. At my side suppress() works in general too:
# grep -c suppress /var/log/messages
  4

but suppress() doesn't work for this issue.

> In your message there is also no "[ xxx.yyyyyyyy]" kernel like monotonic
> clock timestamp in the front of the message which could make them look
> unique ... right?

I cut it away: unnecessary information for bug report when boot
time, and sytem time was.

But I think this is the reason why suppress() doesn't work: the kernel
time is measured in microseconds, and is part of the log message too.
So the message is constantly changing, and suppress() cannot find duplicates
therefore.

*** Bug 810331 has been marked as a duplicate of this bug. ***

It might be worth testing Fedora patch http://pkgs.fedoraproject.org/cgit/syslog-ng.git/tree/syslog-ng-3.3.6-syslog-ng.service.patch?h=f18 to ensure systemd considers syslog-ng "up and running" only when the PID file is created.

Also, comparing what Fedora is doing, they are using :
    file ("/proc/kmsg" program_override("kernel") flags(kernel));
instead of:
        file ("/proc/kmsg" program_override("kernel"));

(not sure it is related..)

@Frederic: the following branch for the upcoming syslog-ng 3.5 version has some patches, which will help syslog-ng to emit proper systemd status messages. It's currently unmerged and untested. Will this be a proper resolution for the problem, once available?
https://github.com/algernon/syslog-ng/commits/feature/3.5/systemd/goodies

(In reply to comment #12)
> @Frederic: the following branch for the upcoming syslog-ng 3.5 version has some
> patches, which will help syslog-ng to emit proper systemd status messages. It's
> currently unmerged and untested. Will this be a proper resolution for the
> problem, once available?
> https://github.com/algernon/syslog-ng/commits/feature/3.5/systemd/goodies

probably. But maybe adding PID option would be enough

(In reply to comment #13)

Are there any news?

syslog-ng 3.5.1 is released, but without man pages, so I'm waiting for 3.5.2 before sending it to Base:System and Factory.

Can we consider this issue resolved ?

I can't reproduce on my opensuse 13.1 and I don't think this has been seen again since this report.

(In reply to Franck Bui from comment #16)
> Can we consider this issue resolved ?
> 
> I can't reproduce on my opensuse 13.1 and I don't think this has been seen
> again since this report.

syslog-ng is quite obsolete and has been replaced by rsyslog in 13.1.
Version 12.3 is out of maintenance anyway, so IMHO, you can close this bug.

(In reply to Thomas Blume from comment #17)
> syslog-ng is quite obsolete and has been replaced by rsyslog in 13.1.
> Version 12.3 is out of maintenance anyway, so IMHO, you can close this bug.

Then you installed a different openSUSE 13.2 than me.

I found source package syslog-ng in official tree (and already replace rsyslog with it):

http://download.opensuse.org/repositories/openSUSE:/13.2/standard/src/syslog-ng-3.5.6-3.1.4.src.rpm

(In reply to Klaus Singvogel from comment #18)
> (In reply to Thomas Blume from comment #17)
> > syslog-ng is quite obsolete and has been replaced by rsyslog in 13.1.
> > Version 12.3 is out of maintenance anyway, so IMHO, you can close this bug.
> 
> Then you installed a different openSUSE 13.2 than me.
> 
> I found source package syslog-ng in official tree (and already replace
> rsyslog with it):
> 
> http://download.opensuse.org/repositories/openSUSE:/13.2/standard/src/syslog-
> ng-3.5.6-3.1.4.src.rpm

Yes, it is still available but per default rsyslog is installed.
I was not aware that someone still cares about syslog-ng, sorry.

So the newer syslog-ng version (comment#15) in 13.2 still shows the issue?
If so, would you mind opening a bug against 13.2 or updating the product version in this bug?

Dont seem to be present on opensuse 13.2:

linux-nypb:~ # grep syslog /var/log/messages 
Jul  2 11:28:04 linux-nypb syslog-ng[500]: syslog-ng starting up; version='3.5.6'
linux-nypb:~ #

This bug was initially reported for opensuse 12.3 which is not supported anymore.

Also I couldn't reproduce it on supported platforms opensuse 13.1/13.2

So closing the bug.