I have a configuration in which journald is set with ForwardToSyslog=yes. Quote from the documentation:

If forwarding to syslog is enabled but nothing reads messages from the socket, forwarding to syslog has no effect.

I am experiencing a different observation with the following test:

systemctl disable rsyslog
systemctl stop rsyslog
logger "rsyslog is dropped, journald won't forward this message"
systemctl enable rsyslog
systemctl start rsyslog

# This shouldn't find anything
grep "rsyslog is dropped" /var/log/syslog
    Mar 15 16:26:23 hostname user: rsyslog is dropped, journald won't forward this message

The result is that rsyslog manages to end up processing the message.

rsyslog has been set without the capability to read the journal database.

My assumption is that socket buffering capabilities are causing rsyslog receive before the time it is running.

If that is the case is it possible to remove this buffering of at least force flushing the socket from bash somehow so rsyslogs history starts together with it?

1 Answer 1


One option is to have rsyslog consume the socket directly and not rely on receiving the data form systemd socket:

# /etc/rsyslog.conf should contain

# cat /lib/systemd/system/rsyslog.service
Description=System Logging Service

ExecStart=/usr/sbin/rsyslogd -n


This has multiple implications:

  • rsyslog wont be automatically started when there are events on the socket (this is what I want to achieve, just being explicit)
  • it isn't clear if this conflicts with the rsyslog code which is coupled to systemd socket activation
  • it seems to be officially discuraged

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .