PEACEFUL systemd thread - Printable Version
+- nixers (https://nixers.net)
+-- Forum: Operating Systems (https://nixers.net/forumdisplay.php?fid=4)
+--- Forum: GNU/Linux (https://nixers.net/forumdisplay.php?fid=12)
+--- Thread: PEACEFUL systemd thread (/showthread.php?tid=2009)
PEACEFUL systemd thread - z3bra - 30-10-2016
So I think most people in there would argues that systemd is a shitty software. It might be, but in most discussions I came across regarding this topic on IRC, I found myself to be in the position to defend systemd, because most people arguments are badly expressed, or simply false.
I would like to start a PEACEFUL and comprehensive discussion about systemd there, in order to help people construct a relatively well-though opinion.
To do so, I think the way to go is to limit ourselves to technical arguments ONLY, and for each arguments against systemd, one one should provide at least one argument in favor of this feature.
Because I tend to be pretty vague, and have difficulties to explain what I want, I'll start by one of the first thing that bother me with systemd: binary logging:
systemd replaces syslog by translating kernel logs into its own format, that is saved in binary data, and accessible through a tool named 'journalctl'.
Logging in binary form sucks for me, at it prevent you from investigating with standard tools, accessing logs through a single file sitting in /var/log. it means that you NEED a tool that can read these logs if you want to investigate them. Standard tools made to operate on text streams won't suffice. Binary data can also be corrupted easily. Add 1 byte padding, and the whole file might become unreadable (I hope they have a mchanism to prevent that, but again it add complexity over something that was pretty simple). Text files can't really get corrupted, as if you add garbage in the middle of a text file, your eyes can simply just ignore that part and continue reading after that. Hopefully, there is a way to forward journald logs to syslog, that will process them in text form, and write them back to files in /var/log. This is just not efficient and coherent at all, as the logs will go this way:
So much useless step and conversion, giving it even more possibility to corrupt data.
The reasonning behind this decision might make sense though, as it was done to give the possibility to "structure" the logs, and sort them in an easier manner by the logger. Like, imagine the binary format written looks like that:
For systemd, reading such a structure is easier, more efficient, and more reliable than parsing a text log entry.
It provides a simple mechanism to search, order and classify logs, which could be real helpful in some situations.
Binary data is also way easier to deal with in terms of code, making systemd "simple" in this case (not real code here, but that's what I'll do if I was Lennart):
Same goes for reading... Pretty simple! Sadly, I doubt systemd would do it in such a simple, and lovely way, thus killing the whole advantage of doing so.
RE: PEACEFUL systemd thread - jkl - 30-10-2016
RE: PEACEFUL systemd thread - pranomostro - 30-10-2016
(30-10-2016, 01:05 PM)jkl Wrote: So I think most people in there would argues that systemd is a shitty software. It might be, but in most discussions I came across regarding this topic on IRC, I found myself to be in the position to defend systemd, because most people arguments are badly expressed, or simply false.
Shitty discussions on the internet? You must be kidding me.
About the binary logging, does journalctl provide a simple method of sorting the logs after priority/date?
RE: PEACEFUL systemd thread - venam - 31-10-2016
(30-10-2016, 01:05 PM)jkl Wrote: http://blog.darknedgy.net/technology/2015/10/11/0/As usual, you always post the most awesome links.
This was quite a long and technical read but one about things I didn't get anywhere else on the internet.
RE: PEACEFUL systemd thread - z3bra - 31-10-2016
(30-10-2016, 05:17 PM)pranomostro Wrote: About the binary logging, does journalctl provide a simple method of sorting the logs after priority/date?
Keep in mind that the structure I gave was just an example usage, I didn't actually read systemd code to get this. journalctl does however provide a way to retrieve logs after a certain date, or by priority, so I assumed these informations are present in the log binary format.
RE: PEACEFUL systemd thread - evbo - 31-10-2016
(30-10-2016, 05:49 AM)z3bra Wrote: Logging in binary form sucks for me, at it prevent you from investigating with standard tools, accessing logs through a single file sitting in /var/log. it means that you NEED a tool that can read these logs if you want to investigate them. Standard tools made to operate on text streams won't suffice. Binary data can also be corrupted easily.
I completely agree, there's too much that can go wrong with binary logging. I will grant that in the time that I used a setup with systemd, it gave me no problems with log corruption, and I found journalctl to be easy to use. However, my experience does not remove the fact that the possibility is there.
My major beef with systemd is the homogenization of control it has over the system. It seems to me that Pöttering and company are looking for issues (whether true or perceived) and instead of contributing to existing tools, or creating tools to remedy these issues, they increase the scope of systemd to take over that problem. This creates the culture and attitude that systemd detractors rail against, in where the ever-growing tree of dependencies causes more software to require systemd in order to function properly.
RE: PEACEFUL systemd thread - z3bra - 02-11-2016
Seeing the beast systemd ease, there are probably multiple mechanism against log corruption, but still, the fact they *NEED* to be accessed through journalctl bother me. I've been using archlinux at work for 2 years now, and everytime something goes wrong, I'm finding myself googling things like "journalctl get sshd logs", or "journalctl increave verbosity". It's definitely not user friendly, or suitable when you don't know what to search.
When there is an issue on a server, you possibly don't know what's happenning. What I usually do (on centos), is skimming through dmesg, /var/log/messages, /var/log/secure and so on to try and discover an issue. With journalctl, it's just too complex... You have no idea *which* logs are displayed to you, so even if you don't see anything abnormal, you can't be sure you checked everything.
On a side note: Anybody can argue about another "non-feature" of systemd? Binary logging is being discussed here but I'm pretty sure there are other topics grinding people's gears ;)
RE: PEACEFUL systemd thread - evbo - 02-11-2016
(02-11-2016, 05:38 AM)z3bra Wrote: On a side note: Anybody can argue about another "non-feature" of systemd? Binary logging is being discussed here but I'm pretty sure there are other topics grinding people's gears ;)
Well since you asked, this is more of an annoyance and gripe then a hard point: The recent addition of systemd-mount really grinds my gears. It goes back to my previous post where the scope creep of systemd really bothers me as it tries to take over more and more core utilities and functions.
RE: PEACEFUL systemd thread - z3bra - 03-11-2016
Well, this is definitely not a behavior I'd encourage, but from their point of view, the idea of controlling EVERYTHING that happens at boot time might look appealing, and they probably realise that they'll have to fight in order to force people to comply with their API. The simplest way they have to get around it is to rewrite everything themselve, so they can implement everything they want, however they want. This is a big task, but they seem to prefer quantity over quality, so this decision makes sense for them.
Now I don't think systemd-mount brings any new feature that would justify this...
RE: PEACEFUL systemd thread - TheAnachron - 03-11-2016
From my point of view systemd is cluttering the linux ecosystem with a near-second kernel, at least if it keeps growing as it is right now.
From a technical view, this is both bad for quality and for testing. The more you combine everything together to a big blop the less testing you can do against it and the more testing is done on the end-user.
This is not a good decision,- to say it nicely.