Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
True the syslog format is simple to use, easy to parse, etc, but it doesn't work all that well for anything more than simple logs.
what are you talking about? none is forcing you to use syslogd if you don't want to use it: apache, nginx, mysql, etc. etc. all of them use their own format and they can simply bypass syslogd . there's no need to add binary format except for the fact that now i could have all those logs corrupted and unreadable where before i could have at least got some part of the information. Sure, i can disable it.. how long before it would be mandatory due to some dependency?
5 seconds less is not going to change my life.
Yes but add those 5 seconds up hundreds of times and they do add up to something. The real question is what are you loosing by cutting 5 seconds off of your boot times? I would assume nothing. And what are you gaining by cutting 5 seconds off of your boot time? You are gaining your time back,
Seems like the pros outweigh the cons to me.
since it's a server we are talking about it's a 5 seconds every 3 months or even more (depending on security issue kernel updates etc. etc.) . so yeah in total i'd save 1 minute per year which doesn't justify all the rest of the problems systemd gives me. We could argue about desktop systems and the given benefits of systemd for that environment but, for servers there are no real gains and there are real pains (i don't want my apache to be restarted if it's crashed i want to go and solve the problem, that is my job and by doing that systemd is actually not helping at all).
Also indexed logging is something that isn't really needed by people with a GUI, it's needed by system admins who actually need to look over their logs. My RHEL7 systems ship their logs just fine with syslog, but when I am on the system I love being able to filter logs with journald. I keep seeing people complain about not being able to grep/awk/whatever through their logs but pipe seems to work fine for me with journald.
it is not complaining about grep awk or sed it's the fact that syslog format is easy to use and be parsed if you know your job. so journald solved a problem that only those too lazy to learn regex or basic unix tools were having . on the other hand journad introduces problems like corruption and unreadability of logs that before we hadn't .
I manage several hundred servers and I would love faster boot times. Nothing worse than wasting my time waiting for a machine to come back online.
It's these kinds of statements that show no knowledge of what part of the boot is the OS and what part is the hardware that make me cry about the current state of system administrators. If a significant time of your wait is for the OS to load, then you've configured your server wrong or are using toy hardware.
By far the largest amount of time taken in boot for servers is the hardware checks. For VMs, boot times are already less than 15 seconds, even including the "hardware check", so that's no big deal.
And, for systems that get rebooted once ever 3 months or so, even a minute isn't really a big deal. The only time I really care about boot times are when I'm running through a lot of reboots on the same system, which is usually only when it is first installed and I'm doing hardware config.
totally agree: on VM boot time is already under 30 seconds which is fast enough. on physical machine 90% of wait time is due to hardware/bios checks, that 5 seconds less is not going to change my life. Let me add: if your problem is having a fast boot/reboot of your server and your architecture rely on those 5 seconds less than there's something wrong in your architecture.
* journald will no longer forward all local data to another running syslog daemon. This change has been made because rsyslog (which appears to be the most commonly used syslog implementation these days) no longer makes use of this, and instead pulls the data out of the journal on its own. Since forwarding the messages to a non-existent syslog server is more expensive than we assumed we have now turned this off. If you run a syslog server that is not a recent rsyslog version, you have to turn this option on again (ForwardToSyslog= in journald.conf).
Link to Original Source