You are not logged in.
Hey this is pretty minor but i wanted to point it out because I spent way more time than I'd like to admit trying to figure this out.
I was just reading through the syslog-ng wiki and there seems to be contradicting info between sections or at least that's how i'm interpreting it.
Section 2.1 systemd/journald integration says :
Keeping ForwardToSyslog=no in /etc/systemd/journald.conf is recommended in order to avoid the overhead associated with the socket and to avoid needless error messages in the log.
But then section 3.1 syslog-ng and systemd journal says
If you wish to use both the journald and syslog-ng, ensure the ... settings ... ForwardToSyslog= set to yes.
So from my understanding unless you are setting Storage=none in /etc/systemd/journald.conf , ForwardToSyslog should always be no because syslog-ng follows the 'journald' journal file as per section 2.1, so I'm not sure why section 3.1 says to use ForwardToSyslog=yes , is there a case where you would like to use ForwardToSyslog=yes when Storage is set to something other than none?
Offline
Feel free to mark the relevant section(s) with https://wiki.archlinux.org/title/Template:Accuracy
Offline
is there a case where you would like to use ForwardToSyslog=yes when Storage is set to something other than none?
Yes.
systemd-journald sends new messages to syslog .
syslog-ng stores them as text
systemd-journald stores the messages in binary format only accessible through itself
A severe crash happens which halts everything
Upon (re-) boot the journald binary storage for the previous boot is found to be corrupt and unreadable.
The syslog-ng logfiles are plain text, usable and have info useful for troubleshooting IF you have ForwardToSyslog = yes
It doesn't happen often, but the impact can be huge when it does.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline