I can confirm this, used it for many years, 3 keywords: efficient, reliable, useful.
all 3 missing on journald,in my experience i saw it inefficient also on configuration level, unreliable because of loosing loglines on crash or reboot and not useful since to look at logs i need 3 commands, verbose parameters and 5 google search to find them.
syslog experience? very efficient also on heavy load production instances, never lost a log, pipe grep and jq and you have the info you need.
so what I experienced is that a default linux install was shipping a rock solid logging system by default, reliable and usable and everybody knew what was where and you will find it. now i just have fancy stuff, units etc and lost all of that.
no I dont need to tune config parameters on a default install to have working basic logging tnx.
> syslog experience? very efficient also on heavy load production instances, never lost a log,
You’re lucky. The original syslog protocol was fire-and-forget UDP (which I believe is still the default, though it’s been ages and I could be wrong) and the daemon was single threaded. I/O or CPU starvation could easily lead to dropped logs.
WHen I provisioned a mid-range dedicated box recently, I went FreeBSD almost entirely so as to not have to touch or deal with anything related to systemd, the worst the thing to ever happen to linux.
The problem with systemd is the scale. Some of it is fine, some of it is actually quite good. But other areas are just replacing existing systems with things worse for the majority of traditional users. Logging, time and dns come to mind.
rsyslog is an incredible piece of software. Every time I'm looking for something to do with logs, opening the docs or googling finds the feature for me and myriads alternatives. I know it still exists and use it heavily on any system I'm in charge of, but there's some regret at having a dual system with journalctl...
I can confirm this, used it for many years, 3 keywords: efficient, reliable, useful.
all 3 missing on journald,in my experience i saw it inefficient also on configuration level, unreliable because of loosing loglines on crash or reboot and not useful since to look at logs i need 3 commands, verbose parameters and 5 google search to find them.
syslog experience? very efficient also on heavy load production instances, never lost a log, pipe grep and jq and you have the info you need.
so what I experienced is that a default linux install was shipping a rock solid logging system by default, reliable and usable and everybody knew what was where and you will find it. now i just have fancy stuff, units etc and lost all of that.
no I dont need to tune config parameters on a default install to have working basic logging tnx.
> syslog experience? very efficient also on heavy load production instances, never lost a log,
You’re lucky. The original syslog protocol was fire-and-forget UDP (which I believe is still the default, though it’s been ages and I could be wrong) and the daemon was single threaded. I/O or CPU starvation could easily lead to dropped logs.
WHen I provisioned a mid-range dedicated box recently, I went FreeBSD almost entirely so as to not have to touch or deal with anything related to systemd, the worst the thing to ever happen to linux.
The problem with systemd is the scale. Some of it is fine, some of it is actually quite good. But other areas are just replacing existing systems with things worse for the majority of traditional users. Logging, time and dns come to mind.
systemd-boot ia actually one of the rare components that are pleasant to work with.
Gentoo also has a systemd-free option (and even if it didn't, you could make one because Gentoo is basically LinuxFromScratch)
WHAT R UR CFLAGS??!?
https://www.devuan.org/
And still does. I generally replace journald with rsyslogd on systemd setups.
The syslog architecture never had a filter component in the middle that could drop logs before they reached syslogd.
rsyslog is an incredible piece of software. Every time I'm looking for something to do with logs, opening the docs or googling finds the feature for me and myriads alternatives. I know it still exists and use it heavily on any system I'm in charge of, but there's some regret at having a dual system with journalctl...
syslog wasn't dealing with it because all of this output was written in .xsession-errors in user's homedir (which was not rotated btw)