Slashdot Mirror
Systemd Adding Its Own Console To Linux Systems
An anonymous reader writes: The next version of systemd is poised to introduce an experimental "systemd-consoled" that serves as a user-space console daemon. The consoled furthers the Linux developers' goal of eventually deprecating the VT subsystem found within the Linux kernel in favor of a user-space driven terminal that supports better localization, increased security, and greater robustness of the kernel's seldom touched and hairy CONFIG_VT'ed code.
srsly?
Before you go round acting like the sky is falling, try educating yourselves about why this is necessary. This is not just a systemd problem, this is a problem for any init system that wants to support multi-seat, and sane switching between VTs:
Now you may say that OMG systemd is teh evil monolith!!1!!!, but before you do that understand that this has been an important feature that has been needed for a long time in any init system it just happened that SystemD solved it first.
[Disclaimer: Yes I hate systemd and I proclaim that loudly. Everything below is my personal experience with systemd and why I hate it.]
If booting the machine up was all it did, then I probably wouldn't care. Most of my hate (I can't speak for the rest of the internet) comes from the fact that systemd does a lot more. It also tracks user logins using a mechanism (control groups) that isn't available in some container scenarios making systemd unusable in those environments (and by extension any distro mandating systemd). It does its own logging in binary which needs a tool to read the logs and if it gets corrupted then systemd's devs say "just delete the logs". Really?
But I think the best reason people hate it is because it makes other applications become dependent on it. GNOME is the most well known example but I've also seen that Centos7's Source RPMs have systemd-specific commands (macros?) making it hard to build them on other platforms. rsyslog doesn't listen on /dev/log because systemd is doing something with the socket now. You cannot start services without systemd being the one to do it.
This is the hate. systemd isn't just an init system, it becomes part of your daily life. I liken it to the MCP (Master Contrl Progam) from the first TRON movie. It's systemd's way or the highway.
No, is monolithic Note the part where he repeatedly gibbers about that stuff is impossible to separate.
CLI paste? paste.pr0.tips!
Except that RC init wasn't fine. More than a few times over the years I've had a service that wouldn't start right on a server that actually prevented boot! Whether it was some stuck PID file that wasn't properly erased on boot, or some other race condition (often a network condition, or a chicken/egg problem),
...it was actually an init script problem, and not a problem with sysvinit at all. Your init script must not assume that /tmp has been cleared before run. When it finds a PID file, it must not blindly trust it. This sort of problem would be readily solved by simply unifying init scripts based on some sort of well-crafted template, but instead we have a daemon to fix the problem.
Ideally none of this should ever happen, but it did. Bugs are there.
Explain how systemd prevents bugs.
Combine that with the fact that init scripts are huge, fragile, hacks
Let's take a look at your three claims.
First claim, init scripts are huge. No, most init scripts are quite small. Sometimes they source a library, but there's nothing wrong with that. The replacement (systemd+unit files+required libraries) is still larger than (sysvinit+init scripts+script libraries). So this claim is clearly false.
Second claim, init scripts are fragile. Init scripts are not fragile. Some people are very lazy scripters. Some init scripts are well-written and they are fault-tolerant. Some init scripts are not well-written, and distribution maintainers should have remodeled them after ones which were. Distributions should have solved this problem by unifying init scripts. I have made the point elsewhere that a simple hashbang and shell script-based processor could permit using unit files as shell scripts, at least for long-running daemons. So this claim is also false.
Third claim, init scripts are hacks. Shell scripting is a central feature of Unix. Therefore, init scripts are not hacks. This claim is also false.
Everything you have claimed about init scripts is false.
As a system administrator I'd far rather mess with a simple ini file to create services than hack a huge bash script,
As a system administrator I'd far rather mess with a simple script file than have to debug the system that's supposed to interpret the unit files. With a shell script, I can simply run the script with -x and see precisely what is happening, even if all I have is a command line and 80x25. With a daemon interpreting a file, I may be lucky enough to get useful information out of strace, or I may have to load a debugger to actually see why my daemon isn't starting.
All other major unix server vendors ditched sysv init for the same reasons as I state long ago.
That's interesting. I looked up AIX, and it looks like they still have init with an inittab. And So does Solaris. From what I can tell, your claim that major Unix vendors have moved on from the traditional init system is also false.
Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice.
Either you haven't been following the discussions here on Slashdot on this subject, or you are a liar. There have been numerous examples in these threads by actual systems administrators who have encountered actual problems with systemd. So while your claim might be true, it points only to your ignorance due to inexperience and lack of investigation.
Uselessd is a validation of the systemd approach. They clearly also believe that init is broken, or they wouldn't be working on the uselessd fork.
This is also false. They believe that systemd is broken, which is why t
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In addition to the other reasons people have given you (bloated, breaks the unix idea of doing one simple thing well, binary log files, doesn't play nice with others, etc), the reason people are rabidly opposed is because of the way it's being adopted, or should I say, thrust upon us. Poettering and friends are not simply making a piece of software and releasing it and getting people to adopt it because it's good and solves a useful problem. They're playing shady political games to force adoption.
Ideally, if you think you have this great new replacement for the fundamental piece of userland software in Linux, awesome! Write it, fork a distro and build your distro around systemd. Use it. Find the bugs. Work them out. Do this long before you start suggesting people run it on their servers. If it's actually better, distros will start including it. Instead they've played political games to force it into really popular distros like Debian.
It's just not ready for prime time. Build it, test it, show us how it's better and we'll be overjoyed to use it. But ram buggy bloated bullshit down our throats for no other reason than your own ego and well, fuck you.
We don't have a state-run media we have a media-run state.
It is pretty sad to see, that after so many comments nobody really has a clue about what the story is about, and what is happening in the Linux kernel.
The kernel VT system has been considered a monstrosity by kernel developers the last decade and everyone is of the opinion that it should be used to user space.
The finally a really smart guy actually attacks and solve the problem. His name is David Herrmann, and he has tirelessly worked on this for years. Systemd distros will get the full support of his research, simply because almost all Linux distros are using, or a going to use systemd. But don't worry, he has provided rich support user space VT's on non-systemd Linux distros, by eg. "ksmcon"
https://github.com/dvdhrm/kmsc...
Here is his fosdem talk:
https://archive.fosdem.org/201...
Here is his blog that will tell you more about VT's than you ever knew:
http://dvdhrm.wordpress.com/
Here is a wiki link about VT:
http://en.wikipedia.org/wiki/L...
Here is an old blog post about the problems with the old kernel VT:
http://dvdhrm.wordpress.com/20...
In short, no need for the systemd opponents to get their panties in a bunch; they can either use Hermanns user space tools, or pretend there isn't a problem and use the present kernel system.
For the rest of us who really likes systemd, this is great news. Thanks to Hermann's work, there will be much better console support for early boot debugging, better security, better keyboard and language handling etc.
A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.
It is when they're all tied together so tightly that you're forced to take all or nothing.
That's the fundamental problem with systemd. This man's last major project was pulseaudio, which most Linux users know only because an entire generation learned that it was the first thing they should uninstall after installing a new Linux release. Years later, it works OK, but only after years of suck beforehand.
You don't get that 'just unininstall it' option with systemd.
Just what kind of corruption have you experienced in journald? It appends records sequentially to log files, the same as any text logger. If you kill your syslog abruptly do you complain if the last line of the file is cut off midstream and doesn't contain a newline? If so, do you have utilities to recover the data that wasn't written?
As far as I can tell journald just appends to its file, and regurgitates the data which is valid on reboot. If the file was truncated, it starts a new file, but doesn't discard any valid data from the old one. That is pretty-much how every database/filesystem/etc works - accept completed writes, roll back incomplete journal entries.