Thomas Spuhler2013-02-02 15:54:22 CETDescription of problem:syslog.ng fill does not start and fill journalctl logsVersion-Release number of selected component (if applicable):current cauldronHow reproducible:Every timeSteps to Reproduce:1.install syslog-ng2.restart system3.type journalctl after a day running4. You get pages and pages of:Jan 30 22:01:08 vbox.btspuhler.com systemd1: syslog-ng.service start request repeated too quickly, refusing to start.Jan 30 22:01:08 vbox.btspuhler.com systemd1: Starting Syslog-ng System Logging Service.Jan 30 22:01:08 vbox.btspuhler.com systemd1: Starting Syslog-ng System Logging Service. Colin Guthrie2013-02-07 10:23:00 CETThe 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=nullin 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.
Anyway, I've just installed syslog-ng on my system, tried systemctl start syslog-ng (systemctl will use '.service' if no other suffix is given for most commands) and it starts. I checked the manpage, and the '-F' option means it runs in the foreground, without 'daemonizing' i.e. Double-forking (like other init systems need). Fri Nov 9 17:09:24 UTC 2012 - [email protected] - Changed to provide a specific syslog-ng.service file which creates an alias to syslog.service while activation instead of using a SYSLOGDAEMON to choose the syslog daemon.
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.
I dont know if its good subreddit. I may have to post it in;)I have a weird problem with syslog-ng 3.6.2 on Centos 7.2 and I don't know how to debug it. Sorry, but I am kind of a noob. When you write:I forget the exact names but look at services and targets named like syslog.socket and systemd-journald.target. You may need to add a dependency to something to ensure a reliable boot sequence.you mean that I may have to edit.service file and add something like 'WantedBy' line, or just install some missing packets dependencies?My /usr/lib/systemd/system/syslog-ng.service file looks like this: UnitDescription=System Logger DaemonDocumentation=man:syslog-ng(8)ServiceType=idleExecStart=/usr/sbin/syslog-ng -F -p /var/run/syslogd.pidExecReload=/bin/kill -HUP $MAINPIDStandardOutput=journalStandardError=journalRestart=on-failureInstallWantedBy=multi-user.target. What is the status of /dev/log immediately after booting the system, when syslog-ng is not logging new entries?On CentOS, /dev/log will usually point to a socket opened by journald, which can optionally send messages to rsyslogd as well. The most likely problem is that your syslog-ng service isn't getting data from journald, it's trying to set up /dev/log, and creating a race condition at boot.In that case, you'd either need to disable journald or (better) configure syslog-ng to get its data from journald:(I think.).
You know what? I was looking at the wrong system (a Fedora system) when I suggested that you check /dev/log, and thought that'd be easier to spot. On Fedora, it's a symlink to a socket that's obviously journald.
On CentOS, the check is less obvious. Do this: # lsof /dev/logCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEsystemd 1 root 28u unix 0xffff00 0t0 8436 /dev/logsystemd-j 661 root 5u unix 0xffff00 0t0 8436 /dev/logHere you can see that systemd-journald, pid 661, has /dev/log open. I would imagine that immediately after boot, you will see the same thing, whereas after you restart syslog-ng, you'd see that the syslogd process has that file open and not journald. If that's the case, then you'd want to modify the syslog-ng configuration so that it gets data from journald, avoiding the conflict over that file.