Bug 8944

Summary: syslog.ng fill does not start and fill journalctl logs
Product: Mageia Reporter: Thomas Spuhler <thomas>
Component: RPM PackagesAssignee: Guillaume Rousse <guillomovitch>
Status: RESOLVED FIXED QA Contact:
Severity: critical    
Priority: Normal CC: mageia
Version: Cauldron   
Target Milestone: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Source RPM: syslog-ng CVE:
Status comment:
Bug Depends on:    
Bug Blocks: 8039    

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