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.

Comments

it solves some unicode issues

[behrooz0az]

Why is everyone so mad about it?
Is it really just me that has a shitload of problems with the current VT?

Re:it solves some unicode issues

[Anonymous Coward]

systemd is turning into an operating system, rather than a service.

When your startup manager becomes more important than the kernel, you might want to rethink your design philosophy.

Re:it solves some unicode issues

[UnknowingFool]

Systemd goes against the KISS principle that Linux and Unix have long followed. However, many would argue that Linux has become too complex for this principle to work when it comes to system management. For user space, it is becoming more of necessity. Those who are using Linux on server side, it seems to solve a problem that doesn't exist.

Re:it solves some unicode issues

[caseih]

Oh really? From the sound of it, VT code in the kernel hasn't been KISS in a long time, certainly not since KML was introduced. Was KML a solution in search of a problem? Hardly. The VT code is full of hacks, bugs, and hard to fix and improve. And we're not just referring to the lack of unicode support, which isn't hugely important. This knee-jerk reaction to systemd is way silly too. One would think Linux users would understand that moving things out of the kernel into userspace is desirable, especially on a server, and especially in an environment where virtualization is the norm. Besides all this,you could just, you know, not run the systemd console daemon. Linux has always supported serial terminals, and will continue to do so. If you're a hardcore server operator (physical or virtual servers) I'm sure you already have this set up.

Re:it solves some unicode issues

[kthreadd]

Systemd is not monolithic. It takes a number of components that used to be developed separately and streamlines them under the same roof, making them work better together. It's is not and there has never been the idea that everything under the sun should go into the same binary.

Re:it solves some unicode issues

[BasilBrush]

And we're not just referring to the lack of unicode support, which isn't hugely important.

... for the minority of the world who are English language speakers. For most foreign language speakers it is.

Re:it solves some unicode issues

[poizan42]

I don't think you know what "monolithic" means. No one said anything about everything being in the same binary. systemd consists of several components that has been designed to only work with each other. There is no modularity in the sense that there is no modules you can replace or decide whether or not to use.

Re:it solves some unicode issues

[rainmaestro]

Don't get me wrong, I disagree with a number of decisions Linus has made. But he tends to be more controlled than Lennart in that regard. His approach is to ignore POSIX when it makes sense to do so (eg, when the standard is too vague to be practical). Lennart seems to want to throw the whole standard away straight out.

I support replacing VT, it is a mess. A mostly working mess, but it could be much better. I just don't trust anything Lennart writes at this point.

Because when something's not broken

[Anonymous Coward]

You fix it, amirite? Seriously, forcing systemd onto server-class systems was a stupid idea to begin with: so, your parallel startup saves me, what, thirty seconds every six months? And for that, I have to give up a proven, reliable startup config for something far more complex? And now it's going to have its own fucking console?

For a desktop, fine, do whatever makes you feel good. But, keep that shit off my servers.

Re:Please stop this madness!

[Anonymous Coward]

Perhaps it's time for an "Ask Lennart Poettering".

I still remember spending a summer loving the FreeBSD single do-all config file (it was the 90s) and being annoyed at Linux's confusing mess of an init system. It's not like Linux init is actually good... it's just a thing you know.

at some point it isnt linux anymore.

[nimbius]

http://boycottsystemd.org/ has generated quite a bit of traction for UselessD, a fork that tries to put the brakes on this flaming deathcab, but its interesting to see what the big 2 are doing. Ubuntu is committed to systemd because shuttleworth wants a "unified" experience and any users that care about their dwindling illusion of free will or choice have long since jumped ship. Pottering works at RedHat so theyve decided to hedge their bets that the server world, which is their bread and butter, is honestly interested in a binary logging monolithic pid0 that has udev and dbus as forced dependencies. user switching and networkmanager are fucking useless to me.

Leonard wont address this fact, but it stands and stands well. RC init was fine. SunRPC was fine. syslog was fine and consoles werent broken to begin with. Whining about mean developers in linux misses the point. you're redesigning something for the sake of redesign and its being done against the wishes of an ethos, the unix ethos, that has served well to maintain some of the most powerful computing systems in the world. There will be a pushback when you have the audacity to imply your linux redesign is a "choice" after a plurality of distributions adopt it.

Re:at some point it isnt linux anymore.

[caseih]

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 happened enough that I modified inittab on all my servers to throw up a login console near the beginning of boot so I could at least log in to try to fix the problem. Ideally none of this should ever happen, but it did. Bugs are there. Combine that with the fact that init scripts are huge, fragile, hacks, and yes you can say sysv init has serious problems. As a system administrator I'd far rather mess with a simple ini file to create services than hack a huge bash script, and have little to no debugging capabilities, no process supervision, and no easy way to control how many instances of the daemon can run.

All other major unix server vendors ditched sysv init for the same reasons as I state long ago. To my knowledge, of the major important players, only Linux and BSD still use sysv init. The world has not ended, and the sky has not fallen. Life goes on, and Unix and Linux continue to do well and provide stability and reliability. In fact, all I see here is vitriolic teeth knashing. I've yet to see anyone with a specific argument against systemd. It's really disappointing, actually. I think I read one criticism from a developer of another init system that was actually insightful and valid. Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice. RHEL's mailing list has nary a mention of it. It just works and works well. 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. Will be interesting to see their approach to the VT issue. Competition is good.

Re:Or we learn from others mistakes

[BlackPignouf]

That.
I cringe everytime I see "é" "ö" or "á" in folder/file names.
Even if you can, you probably shouldn't, just because it'll break at least one or two programs.

Re:Just fucking leave it alone!

[thieh]

openBSD should be more secure in comparison. Seriously though, the systemd people should look into limiting the interdependencies of their projects. That find of interlocking makes it lacking portability. If they want to replace VT, do that in a way that doesn't make it dependent to everything they have ever made.

Re:Or we learn from others mistakes

[gnasher719]

I cringe everytime I see "é" "Ã" or "Ã" in folder/file names.

I cringe every time someone has a problem with accented characters in folder or file names.

And it doesn't break any programs. Those programs are broken already.

Re:UseLessD

[smash]

Or you could use what we've been using for the past 20-30 years that has been debugged, proven to work and not completely different to the rest of the world.

Slashdot Response

[inhuman_4]

Article: Old, crusty, and possibly bug ridden part of the kernel is being moved to userspace. This new work will increase both the security and the stability of Linux systems, while adding the possibility of internationalization support.....

Slashdot Comments: Finally some one is doing something about CONFIG_VT. People have been bitching about that for years!

Article: this new feature is part of systemd.

Slashdot Comments: NOOOO! Why is Lennart taking away my freedoms! I'm switching to BSD.

It has gotten pretty clear that a lot of the hatred for systemd has nothing to do with the technical merits. This is a fix that has been a long time coming. Yet, almost half the comments are just more systemd hate fest.

Re:Or we learn from others mistakes

[BasilBrush]

It's 2014. There should be no forgiveness for software that doesn't use Unicode correctly. With the supposed superiority of open source and the ability of any programmer to dive in and fix bugs how is this still a problem for Linux?

Re:UseLessD

[Anonymous Coward]

[citation needed]

I've seen no announcement on the Debian CTTE list that verifies your claim. Do you have a link supporting this, or did you just pull it out of your ass?

Re:Please stop this madness!

[The Technomancer]

It's less about rewriting scripts (from my understanding, systemd does a bang-up job of supporting init scripts unmodified), and more about the major distributions in use on the server side of the house (RedHat and its derivatives, Debian and its derivates) making it the New Way Forward. It may very well be an improvement over the current init system. For desktops and mobile where boot time matters significantly more than stability, it should be the new way forward.

But on the server side, nobody gives a crap about boot time. If you're on physical hardware, it should be happening rarely. If you're using a cloud architecture, it should happen all of once per instance. To keep my log management installations working properly, I need to add the extra overhead layer of having systemd's binary logs reprocessed and forwarded to syslog. Not a big deal until you do the math and realize that an extra half percent of overhead is an extra box or instance needed per 200. I also ned to devote sysadmin or devops time to doing some thorough testing for stability.

This is all a very roundabout way of saying that it's unclear if systemd is an improvement for the server side of things, and that even if it is an improvement, it's not enough of one to be worth all of the resources needed in an enterprise-grade installation to justify switching to it, nor am I comfortable being an early adopter on anything other than my personal lab kit.

As far as the developer goes? He wrote software. It's not his fault that the project managers of the major distros have decided that shooting for the desktop and mobile is more important than supporting the server side people that have been paying their bills for decades. Be pissed at them for this.

Re:Awesome!

[godrik]

This should not be tagged funny! This should be tagged depressing.
What I really don't understand is "why is this part of systemd and not a separate program?" I can only see two answers:

-Because it has to be tightly integrated with systemd. In this case, I would rather we do not clutter a critical system component with more unnecessary code such as a console implementation.

-Because it is a tactic to get it deployed as part of the systemd package. In which case, systemd really starts looking like a attempt at conquering the world. I feel like that is exactly what it is here.

Nobody deserves death threats.

[emil]

systemd managed to replace init, inetd, and some of cron in what appears to be a stable environment. This allowed systemd to work in docker and drastically improve Linux virtualization to leapfrog Solaris zones.

What systemd did not do was provide reasonable documentation. RedHat's v7 inittab has a website for a blog post that sucks. There is no general intro for users attempting to create crontabs executed by systemd, inetd entries for common services, and runlevels that control groups of processes.

systemd fell down hard on documentation, and the first blush with the unix admin crowd has not been kind.

These developers delivered working code in a radically new environment, but without documentation the architecture appears to discriminate against people who have been doing things the same way for 30 years. The authors, and their software, appeared cliquish and discriminatory. Had the software and the documentation enabled a gradual migration into a more powerful architecture, things would have been quite different.

In any case, this is no justification for people to be vile. The old crowd needs help into the new environment. This help needs to happen, and the insults and threats need to stop. Both sides need to work together to get us where we need to be.

This Is Lennart's Defense?

[ewhac]

Every time the systemd thing comes up, I want to hate it, but I don't truly know enough about it to actually hold a defensible opinion.

One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.

Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:

Since this bugyilla [sic] report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:

Well, yeah, corrupt logs would be regarded by many as a major bug...

...Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.

Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.

Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.

Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!

....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.

And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"

File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.

....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surpr