Slashdot Mirror
Ubuntu To Officially Switch To systemd Next Monday
jones_supa writes: Ubuntu is going live with systemd, reports Martin Pitt in the ubuntu-devel-announce mailing list. Next Monday, Vivid (15.04) will be switched to boot with systemd instead of UpStart. The change concerns desktop, server, and all other current flavors. Technically, this will flip around the preferred dependency of init to systemd-sysv | upstart in package management, which will affect new installs, but not upgrades. Upgrades will be switched by adding systemd-sysv to ubuntu-standard's dependencies. If you want, you can manually do the change already, but it's advisable to do an one-time boot first. Right now it is important that if you run into any trouble, file a proper bug report in Launchpad (ubuntu-bug systemd). If after some weeks it is found that there are too many or too big regressions, Ubuntu can still revert back to UpStart.
There's always Slackware. I still use it as "go to" distro for both desktop and server roles. It's not as sexy other distros but there's no better way to learn Linux. I highly doubt Patrick is going to jump on the systemd bandwagon any time soon, if ever.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
It's a system for managing the start, stopping and restarting of system services and a whole other slew of important system tasks. Unlike previous init systems, it does its job significantly better.
Unfortunately slashdot is filled with armchair sysadmins who are upset they'll have to learn something new, while the real sysadmins are out their already using systemd in production. More systemd, I say.
But but Fedora has been using it for years without issue! Oh wait, that's because no Admin in their right mind would use Fedora as a server. But but it is stable and secure. Oh wait, your high load servers keep corrupting the journald and journalctl can't read portions of it without trying to replace the who journal with a new one. But but you can install rsyslog to fix that! Yeah, because we ALL like having to beta test an unproven product in a production environment only to be forced in resorting to something else that actually works as intended.
I'm caring less about systemd and more about how shortsighted they were when they forced everyone to use journald. The fact that I have to configure rsyslog to have a working log that does not constantly get corrupted and restart a new log, erasing the old one is annoying and shows just how unproven this entire systemd implementation truly is.
As an OS X user, you know it as launchd.
The upstart team will be disappointed.
Here are two interesting talks presenting the two approaches: systemd vs Upstart for Debian.
I learned a lot about what systemd actually is and does.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I am not especially well versed in the systemd vs sysinit issues. However, it is my understanding from reading other posts and articles on the issue is that those who are complaining about systemd are concerned unhappy with the non-linuxy way systemd approaches system process management.
What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well. One system for initializing processes on bootup. One for scheduling jobs after boot-up. One for maintaining logs, ecetera. It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process. The SystemD promoters believe the integration will make it the management of processes more efficient and cohesive. Those opposed believe it will make a monolithic process manager that in the long run will take more effort to maintain and offer less flexibility.
That is my understanding looking in from the outside.
The init system handles the initial startup of a linux os. It's been acknowledged for some time that it has some limitations, especially in terms of threading and dependency management but for the server world that's usually not that big a deal since the primary users are technical specialists who are comfortable mucking around with that sort of thing. For desktops and mobile devices though those are more serious concerns because they impact user experience and many users don't have the skills to modify things themselves. Systemd is a replacement for init.
PROS: It has faster boot time and more sophisticated dependency management
CONS: It's new (which means lots of people who understand the current system will have to relearn how things work), it's harder to directly customize (requires a higher level of skill to modify), it's a more monolithic design (which violates the linux design principle of do one thing and do it well), it uses binary log files (which violates the linux principle of everything is a text file) and it's taken on a larger number of roles than many feel is appropriate for a single subsystem.
In short, it's probably an improvement for desktop & mobile users who mostly don't care and it's a pretty big inconvenience and possible downgrade for systems administrators who manage servers.
As an OS X user, you know it as launchd.
And all the people whining about how systemd is the ruination of all that is hole-y in Linux conveniently ignore, OS X switched over to launchd (from its previous use of init rc, IIRC) way back in the 10.4 (Tiger) days.
And guess what? Virtually no one noticed. The sky didn't fall. Legions of OS X admins didn't crawl out of their holes to proclaim that the switch to launchd (which, BTW, Apple created and Open-Sourced, thankyouverymuch) was the end of civilization as we know it, blah, blah, woof, woof.
Linux fans are SUCH luddites...
Ubuntu 15.04 is not a LTS release, it's a testbed for features looking to be included on the upcoming Ubuntu 16.04 LTS.
It is not recommended for production systems. If you want the latest stable version, use Ubuntu 14.04.2.
Train crashes cannot be moderated.
Fedora is a testing ground for Red Hat Linux, you know, the predominant server distribution. Red Hat Enterprise Linux have systemd starting with version 7.0 and Ubuntu just joins the ranks of every other enterprise Linux distribution to use systemd, like SUSE Linux Enterprise Server and Mageia. So, you are ignorant of the facts to call systemd an "unproven product".
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Here is one of many:
https://bugs.freedesktop.org/s...
The TL;DR resolution: journalctl --fsck after rotation or pump it into a traditional syslog
Lennart Poettering's comments about it:
"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"
I'm using Mint 17, and I also had trouble getting it to mount my Galaxy Note 4. FYI, I was able to solve it with about 15-20 minutes of Googling + a reboot.
Except that the ACA had laudable goals and was basically embraced by everyone except the Contrarian Party. Systemd has no such support and nobody wanted it from day 1.
Kinda sorta. You missed the fact that init itself is also a process manager. In that it's responsible for starting and stopping processes based on runlevels. (Yes, init can start and stop processes on runlevels)
There's a nasty hack called SysVInit that adds a bunch of shell scripts to init in order to try to replicate the functionality of init. This is done because instead of fixing init's fundamental flaw, people decided to hack a workaround and create a lamer version of a process manager and its hacks. The flaw? Init relies on /etc/inittab for all its process management information needs. One file makes it extremely non-trivial to add and remove services from it programmatically.
It's why we have to deal with daemons that monitor other daemons that restart daemons should they quit (something init does quite well - even handling cases where a daemon restarts too quickly by pausing it so it doesn't hog system resources).
And on another note, we have userspace versions of init that manage user processes on login. The desktop/mobile use cases often have per-user applications that startup and run in the background for the user, and need to be managed on a per-user basis.
So in the end, we end up with the system master process manager, init, a set of hacks and shell scripts to try to emulate it (SysVInit), and one for individual users who wish to have personal services run. Because it's more unix-y to hack three different tools that do almost the same thing, but each with their own limitations and idiosyncrasies rather than one tool to do the job well.
What I mean by that, is traditionally the Linux "Philosophy" regarding the OS system and tools is that it should be made up of a collection of small stand alone software pieces that each do one small job and do it well.
To be clear, the unix philosophy is much deeper than that. Here's an example. Here is a different set.
IMO the only way to describe the unix philosophy in a single sentence is, "write good code."
"First they came for the slanderers and i said nothing."
Why is everything connected to systemd pushed out in such a hurry? Why isn't systemd getting proper time for review?
Is it not obvious? They are trying very hard to get it in everywhere before people wake up. As their technology sucks badly, they have to force too short testing intervals so people will not find too many of the problems. If this were a stable, feature complete piece of software that actually solves the things it is targeted at well and significantly better than the alternatives, there would be no need for rushing it out in such an unprofessional manner.
Here is my take on it and why systemd is a problem, not a solution:
-----
Not that I can be sure, but at I see:
- No technical merits of systemd that are important or critical, just some convenience issues
- Systemd is in hurried development, a stable feature set is nowhere in sight
- The development leads are known incompetents with inflated egos and no communication skills
- There are a number of design decisions that are very, very bad for security and stability
At the same time I see:
- Systemd is pushed strongly with emotional (not factual) arguments
This is a coordinated and targeted propaganda campaign. A campaign focused on technical merits is not even attempted seriously.
- Systemd opponents are ridiculed, insulted and their arguments are not taken seriously
- Systemd is getting very hard to avoid
I can only deduce that there _must_ be one of or a combination of the following going on:
- Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
- Linux did not generate enough support revenue for Red Hat and this is intended to fix that
- Red Hat wants total control over Linux and systemd is their attempt to establish that
So if it walks like a duck, quacks like a duck, the most probable explanation is that it is a duck and hence I conclude that something nefarious is going on and the last three items are the most likely candidates IMO. I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves. They must have significant, coordinated help, with significant propaganda and manipulation experience. Whether it is military PsyOps or just commercial PR, the effects are the same. And they are massively negative and destructive for Linux and its community if not repelled decisively.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Seriously? Puppet Labs has supported it for 5 years now. Managing a slackware sever or servers is no harder or easier than any other one. Now, if you're hand rolling special snowflakes and have no strategy to manage them, sure. But that would be true for any distro or OS.
In fact, launchd was a godsend in the early OS X days. Instead of a mishmash of INIT and Classic MacOS nonsense (/Library/StartupItems), you ended up with one system that could handle per-user agents as well as system daemons, process monitoring and respawning, jobs defined in the same property list format everything else in the system is, and a scriptable interface (launchctl) for simple administration.
Then they open sourced it. And nobody decided to use it, even though it has been bulletproof for 10 years now.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Note that sysv init only does anything useful for 3 use cases:
-booting the system
-shutting down the system
-changing run levels (which both of tje above are considered to be)
On most machines these days, no one changes run levels more than once or twice a month.
Note that sysv init does absolutely nothing for stopping/starting or restarting services without changing run levels. All of this is done by scripts (that are compatible with sysv init) which are unique for every family of distros, and mainly source lots of othwr shell scrupt libraries. They also have different locations for the config files these scripts use.
Packages that are made to work on multiple distros need to ship their own tooling (which dulicates this but pften with their own bigs or misfeatures) to do what the 'init system' should provide standard interfaces for.
On a sysv init system, you can't even be sure you are starting a service the same way the previous admin did, because his environment (PATH, LD_LIBRARY_PATH etc.) might have been different. Compare the /proc/$pid/environ of a service started at boot to one that has been restarted since ...
systemd is noy perfect, but it is much better in all of these aspects.
Systemd stores a lot of metadata in the journal, not just simple text rows. A custom format allows this to be queried very quickly.
a site for you http://www.amazon.com/Aluminum...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Don't get your panties in bunch just because you discover that the journal is "corrupted"; usually it is just trivial stuff like a malformed timestamp or a field value that isn't valid in a single log entry. journald actually test and validate incoming log messages and report errors as it finds them. Even then, you can often read the log entry, but of course, the invalid field value will be missing.
The reason why people discover "corrupted" journal log files is because systemd's journal have integrity checks, unlike syslog who doesn't and where the admin therefore never will know if there are spurious or invalid log entries unless he happens to stumble upon them by chance.
Seriously, if you really care about each and every log entry, you should never have been using syslog anyway; it simply silently drops messages under load, and both local and remote logging are inherently unreliable. Yeah, I know Rainer have made a signal-safe syslog library, but does anybody actually use it?
There are simply too many Linux newbies who seems to be unaware of decade long struggle to improve the many, many problems with syslog. The "rsyslog" team have fought heroically, but often in vain, to try to fix many of the problems.
Syslog, like cron and SysVinit are among the several pieces of Linux infrastructure that can't be changed or radically improved. Because if you change your syslog/cron/SysVinit implementation, it would be incompatible with syslog/cron/SysVinit, so no one would use it, because user space programs doesn't support it etc. A circular dependency that prevent all progress. The systemd project have finally broken Linux free from that quagmire, so now we can actually have Linux infrastructure developed in the same pace as the kernel and user space programs and daemons.
systemd's journal is, warts and all, a massive improvement over the what existed before.
The question is: "What is the maximally fucked-up linux distro?"
Well, that would be Suicide Linux, obviously.
my, your, his/her/its, our, your, their
I'm, you're, he's/she's/it's, we're, you're, they're
Link: Suicide Linux
my, your, his/her/its, our, your, their
I'm, you're, he's/she's/it's, we're, you're, they're
I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves.
I don't think it's that bad, they don't have to convince the entire 'tech-savvy community,' they only need to convince a very small subset of that community, the people who are writing init scripts for distros. And that subset is very small.
Systemd knows that very well. They've worked very hard to make init-script writers happy, and have been very responsive in making changes. If you look through the Debian mailing lists, you can see this......there's no need to blame the NSA or others. They're just following a useful principle: find the ones who have power to do what you want, then make them as happy as possible. The systemd people have done that.
"First they came for the slanderers and i said nothing."
The bug report linked by kolbe (https://bugs.freedesktop.org/show_bug.cgi?id=64116) is, IMO, a very good read to give a quick glimpse of the fine lines between the two camps (pro-systemd; anti-systemd).
Poettering's first reply/answer was simple, "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."
That embodies the "here's a bug; our answer is to say it's a feature and not a bug; NOFIX" that some people feel.
He then follows it up with a much longer reply because, "Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd". I'm not quoting out of context - that's the first sentence of his reply. Regardless of the motivation to his reply, the reply was much more thorough and he seems to truly want to help others understand. IE. I think it shows some of the good side there.
However, I'm still anti camp, and I'm not there because bugs like this are not directly fixed. I'm anti because of the underlying assumptions that are needed in order for his reasoning to be justified. In this case, that reasoning only works if one assumes the need for a binary log whose format includes re-writable parts at the front of the file, and whose corruption results in an non-repairable state. However, if the format is such that, after corruption, it's difficult or impossible to fix, why are they using that format?
FWIW, that specific bug report was, "How does one fix journal corruptions?". In that context,his answer is completely sufficient - you don't. The next question seems obvious to me though - how do we avoid that in the future? Currently, it seems that the systemd solution is to make the log reader more intelligent so that it can handle the corruption, like an FSCK, and read as much as it can.
Personally, I'm really hoping that uselessd matures and becomes commonplace and easy to drop in. It's not ideal, but it seems that systemd is going to be everywhere through the Linux community, and there's no good way to avoid that at this time. Uselessd would at least allow someone to use alternative init systems while still being able to use modern applications and environments without crippling them. Regardless of ones opinions on systemd and other init systems, the ability to swap out a subsystem is something that we should all be able to recognize as valuable.
If everyone hates systemd so much, why is it being incorporating into all these Linux distributions? Have all the major ones incorporated it? Does this "evil" Poettering guy really have that much clout in all the disparate distros?
The systemd haters are actually a tiny but vocal minority. They tend to flash-mob systemd threads, so you can often see here on slashdot, how a little handful of systemd-haters post 10-20 anti-systemd posts in anything remotely related to systemd. They seem like they are many, but when counting they are quite few.
No distro have lost users because of switching to systemd, in fact, systemd is part of the whole OS container wave that are fuelling the Linux engine at the moment. Not a single non-systemd commercial Linux distro have emerged since all the major Linux distro announced their shift to systemd, so the server market seems firmly behind systemd.
One reason why Canonical is changing to systemd as fast as it can, is because their OS container costumers are impatiently tapping their feet, waiting for systemd integration.
People have started to ignore this small, sometimes very toxic minority for quite some time, since the anti-systemd people are basically uninformed about any technical aspects of systemd, because they rely on hearsay and random hate blogs for their information about systemd instead of actually reading the systemd documentation.
Here is one of many:
https://bugs.freedesktop.org/s...
The TL;DR resolution: journalctl --fsck after rotation or pump it into a traditional syslog
Lennart Poettering's comments about it:
"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"
Totally sensible solution, why would you edit log files? They are not meant to be changed.
Besides that, the log entries that are mangled are in them self important info; How can you detect a pattern of a misbehaving program that sends wrong field values if you delete the entry every time it happens?
Or what if the log corruption is caused by a failing disk where the bad blocks are spreading like wildfire? If you silently delete such entries and files, you delete the evidence for that something is wrong.
Fascinating. You have not the least clue what you are talking about. Obviously nobody with the least bit of clue would expect logs to be cleanly written on failing disks, hence this is not even a subject for discussion. As to rsyslog, you really are utterly stupid: Failing disks or filesystems are detected rightfully by the kernel, nothing else has any business doing so. Different from systemd "logging", rsyslog will not make the log problem worse by using a binary format and a broken flush strategy, and for remote logging will transfer the messages off-site.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Wow, what the hell do you take us for? Aluminum foil? Aluminum foil?! The shit you put on your TV antenna to get better reception? Yeah, yeah, that's really going to block the government mind control rays.
Jesus. Tinfoil man. Tinfoil.
We don't have a state-run media we have a media-run state.
Really, though, if you're sticking anything but an LTS version onto bare hardware you're asking for trouble. They're very up-front about non-LTS releases like 15.04 being barely-supported betas for LTSes. So in that sense rolling out systemd at this stage is a pretty good idea since they'll have a year to work out kinks before 16.04, while IIRC they switched to PulseAudio not long before the LTS 8.04 release, with disastrous results.
Init is still good for many applications (and completely satisfactory for server use). If somebody tries to prevent me from using it or to make that hard, then these people become an enemy. The systemd crowd qualifies.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Gimp doesn't seem to depend on systemd (here is a brief discussion on the topic). It seems to be a rumor, but I don't know where it started.
"First they came for the slanderers and i said nothing."
Systemd causes log corruption where sane alternatives do not have such issues. Ever wonder why?
Utterly false. The idea that syslog doesn't have corruption is false. I have seen syslog corruption many times. Whether it's truncated lines, merged lines because half of an old truncated line has a new message appended, blocks of 4k zero bytes, or single bit or single character errors.
In particular if a syslog file is truncated mid-line by either disk full, system failure, filesystem bug or drive bug, the best thing syslog could do when it resumes after boot would be to rotate log files at that point, instead of appending to the truncated file.
These are quite rare, but not so rare that I haven't seen them maybe 50 times in 20 years in Linux syslog files.
I have no opinion on systemd particularly, but with regard to this single thing of rotating logs on detecting corruption, instead of attempting to patch the corruption or continue appending to the file, I think the right decision was made, from the perspective of an admin wanting the best available information after a problem.
> Have better hardware, have a RAID, transfer the log messages over the network, have a UPS on your computer, invent a time machine.
You do realize this happens regardless of what hardware you are running. In my case, I have a VCE VBLOCK 720 running VMware Vsphere 5.5 against an EMC VMAX 10K that is only only 40% full and has 1ms FC latency across an ALUA mode4 (MPIO least-connect) configured path.
The issue isn't some out of place one off situation, but rather a consistent issue that other admins have experienced while running applications like Oracle E-Business Suite (EBS), SAP and Oracle RAC 12c with high limits of logging facilities. Visit VMworld, go to a VMUG, a VCE UG or any other group that runs lots of priority 1 applications on high end systems for their corporate environment and you will hear the same issue crop up in conversation many times.
Transferring log messages via rsyslog or snmp traps is CURRENTLY the only resolve here and it is one I find to be annoying.
"The next question seems obvious to me though - how do we avoid that in the future?"
I do not know, I am not a programmer. All I can say though is that it is an issue where the systemd camp has yet to satisfy sysadmins.
No, systemd detractors really is a tiny minority; some ways this really shows is how there are almost no developers working to maintain even critical needed infra structure for non-systemd distros; ConsoleKit has been abandoned for years now, eudev is just a shadow fork of udev with no independent development going on, and several key components like systemd-shim and cgmanager are only kept alive by paid Canonical developers and a few Debian devs; once Ubuntu and Debian shifts to systemd, those projects will languish too. SysVinit will properly also deteriorate completely; Red Hat/Suse was the defacto upstream before, and now it is only Debian as long as it last. So the non-systemd infrastructure will probably deteriorate further as the commercial distros stops to maintain it.
In short, almost no developers are working on maintaining non-systemd infrastructure, this reflects how few the systemd-detractors really are.
The recent Debian debate also show how few the systemd detractors really are when the numbers are shown: The system-detractors made a lot of noise on the Debian mailing list, but after the technical committee had decided that systemd should be the new Debian Linux init system, the detractors were unable to even gather 5 (like in five) Debian developers out of around 1000 to sponsor a vote on this subject.
Even the GR bill trying to keep other init-systems equally supported was clobbered at the GR vote.
So going by the noise on the mailing lists, the systemd-detractors seemed like a force, but when voting they where nowhere to be seen.
Same with Linux distros; you would think that the non-systemd distro ranks would be swelling with the numbers of systemd-refugees. This certainly doesn't seem to be the case. A couple of rather obscure distros like Funtoo and Void are among the few distros that don't want to support systemd. Slackware is undecided on the issue, and Gentoo etc. support systemd, with a growing number of its users that prefer it to OpenRC.
Also no medium/major commercial non-systemd Linux distro have emerged this last couple of years, this is a strong indication that the paying costumers wants systemd, and doesn't care at all for the alleged superiority of SysVinit. Several companies made it clear during the Debian debate that they favoured systemd, none spoke for SysVinit or Upstart.
No wonder; systemd is great and it solves real world problems like daemon management and security much better than any other alternative.
What are you talking about? In the core systemd have only 5 daemons: systemd, journald, networkd, logind and user session, and it depends only on dbus, cgroups, autofs and kdbus. That is very minimalistic. The rest are optional daemons and tools that make your life easier.
http://en.wikipedia.org/wiki/S...
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute