Bug 8944 - syslog.ng fill does not start and fill journalctl logs
Summary: syslog.ng fill does not start and fill journalctl logs
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal critical
Target Milestone: ---
Assignee: Guillaume Rousse
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 8039
  Show dependency tree / graph
 
Reported: 2013-02-02 15:54 CET by Thomas Spuhler
Modified: 2013-02-11 22:30 CET (History)
1 user (show)

See Also:
Source RPM: syslog-ng
CVE:
Status comment:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Thomas Spuhler 2013-02-02 15:54:22 CET 
Description of problem:
syslog.ng fill does not start and fill journalctl logs

Version-Release number of selected component (if applicable):
current cauldron

How reproducible:
Every time

Steps to Reproduce:
1.install syslog-ng
2.restart system
3.type journalctl after a day running
4. you get pages and pages of:
Jan 30 22:01:08 vbox.btspuhler.com systemd[1]: syslog-ng.service start request repeated too quickly, refusing to start.
Jan 30 22:01:08 vbox.btspuhler.com systemd[1]: Starting Syslog-ng System Logging Service...
Jan 30 22:01:08 vbox.btspuhler.com systemd[1]: Starting Syslog-ng System Logging Service...
Manuel Hiebel 2013-02-03 13:22:55 CET

CC: (none) => mageia
Blocks: (none) => 8039
Assignee: bugsquad => guillomovitch

Comment 1 Guillaume Rousse 2013-02-06 22:50:24 CET 
Reproduced. I'll see with upstream.

Status: NEW => ASSIGNED

Comment 2 Colin Guthrie 2013-02-07 10:23:00 CET 
The reason it keeps getting started by the way is due to syslog.socket triggering it which seems to avoid start rate limiting.

Finding out why it exits on startup would be nice. It seems to exit with code 2.

Digging a little more it seems to say:
Error creating persistent state file; filename='/var/syslog-ng/syslog-ng.persist-', error='No such file or directory (2)'


This is not shown in typical journal output because of the line:
 StandardOutput=null
in the syslog-ng.service unit.

This is likely required in a syslog to prevent circular loops - e.g. if it outputs it's logs on stdout, then the journal captures the output and forwards it on to syslog which logs it and outputs it on stdout which the journal captures and forwards to syslog which is output to stdout which is... you get the idea :)

It makes debugging syslog service more tricky than others.

Anyway, all that was needed to fix it was "mkdir /var/syslog-ng/" so likely just a packaging error.
Comment 3 Guillaume Rousse 2013-02-07 10:25:24 CET 
Indeed, a wrong argument was passed to ./configure call. However, just fixing was not enough for me.

Upstream suggest to replace system() source instead of /dev/log in default configuration, I didn't tested yet.
Comment 4 Guillaume Rousse 2013-02-07 20:45:32 CET 
Should be fixed by incoming 3.3.8 release...
Comment 5 Colin Guthrie 2013-02-08 11:49:20 CET 
(In reply to comment #2)
> The reason it keeps getting started by the way is due to syslog.socket
> triggering it which seems to avoid start rate limiting.

FWIW, at the systemd side, I'll add http://cgit.freedesktop.org/systemd/systemd/commit/?id=464876c9c410b2f5bb997259510a13d0ee7d0af0 to my cherry picks which should stop the logs filling up under these circumstances.
Comment 6 Guillaume Rousse 2013-02-11 22:30:46 CET 
Fixed now.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED
Note You need to log in before you can comment on or make changes to this bug.