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.

Comments

Delicious geek tears.

[Anonymous Coward]

Yes, yes spout your endless platitudes about how you're switching to slackware and BSD. You know you can't resist.

We've heard all this shit before, going on more than a decade. Kernel 2.0, audio systems (several!), firewall schemes. The drama is endless and there's nothing entitled basement crawling self proclaimed sysadmins won't bitch about.

This is just another evolution that meets more people's needs than your own special pet niche.

Do it. Start your fork now. Put up or shut up. Just stop whining.

What is systemd exactly?

[ArcadeMan]

Can someone explain to us Windows and OS X users, without using acronyms and Linux-only mumbo-jumbo, what exactly is systemd and why do we keep hearing so much about it?

Telling us to go read a wikipedia page probably won't help because it will be either too long to read, too complex or require knowledge about other topics to understand.

Re:What is systemd exactly?

[Anonymous Coward]

Don't forget that SystemD also has integrated into it, boot manager(not INIT, think GRUB), DHCPD, DHCP, an actual NAT, Firewall interfacing, keyboard culture, time settings, USB notification. etc etc. At one point, if your logging didn't work, it broke your keyboard so you could not terminal in. Don't you love it when two unrelated services with no logical dependencies can some how affect each other?

Re:What is systemd exactly?

[Anonymous Coward]

At one point, if your logging didn't work, it broke your keyboard so you could not terminal in.

Source? A quick google of "systemd logging keyboard issue" didn't turn that up.

I've only recently started trying CentOS 7, so I'm still getting a feel for systemd, but I haven't had a lot of problems doing the stuff I usually do in 6.x - first time I try something I might have to google it, otherwise no real issues.

Re:What is systemd exactly?

[ledow]

Collate all the thousands of customised, random and disparate init scripts that start up the system (what services to run, in what order, when to mount the filesystem, how to do so, what flags to use, how to tie it all in so you boot properly every time, etc.) into a handful of huge binaries that do some clever magic to do roughly the same job (maybe quicker, maybe more reliably, maybe not - there's evidence both ways depending on the usage case in question).

The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems. Systemd is tying into everything from initial boot to how to configure your soundcard.

On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.

It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.

I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.

On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.

More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.

It doesn't help that personalities on both sides fan the flames in the heated debate.

Re:What is systemd exactly?

[PPH]

then you need to know that "sudo service apache2 restart" is now "sudo systemctl restart apache2" (probably) and that is about all you need to know.

But the System V "apache2" is a shell script. On my minimalist laptop, its about 300 lines long. On an actual production server, I imagine the admins have added quite a bit of additional status checking, cleanup and initialization smarts to this script and it is several times as long.

Back when systemd was first proposed, one of its goals was to "speed up" booting by eliminating init scripts. Each which consumed some resources starting its own bash instance. It was actually a bunch of people unfamiliar with modern o/s operation who were getting butthurt over the fact that a freshly booted *NIX system had "consumed" several thousand process IDs. Seriously. I split my sides over this argument, having run many systems that have 'wrapped around' PID numbers several times.

Now, all of this shell script pre-processing is gone*. Systemd seeks to 'clean up' the boot process by launching executables directly. And this is what many sysadmins are upset about. They will have to find a new home for all the startup processing that they have tuned. And that will break stuff until the conversion is done.

*Or the service developers will just arrange to have systemd run their old System V scripts. Which puts us right back to where we started.

Re:What is systemd exactly?

[CurryCamel]

That baffles me too.

But I guess your have your 'minority' and 'majority's mixed. A more powerful minority - the distro makers - make this decision (and they seem terribly non-vocal, I'm still hoping someone would explain in simple terms why systemd is a good thing. No, cutting down the cold boot time from the ~20s it is with init is not a terribly good reason in my book).

I don't like systemd, but I am not that vocal about it. I don't know it closely enough to comment. My experience with systemd is as follows:
-About 99% of linux crashes (subjective measurement) I have seen in the past 10 years happen on my Fedora box. The only one I have that runs systemd. Coincidence? I don't know.
-The same Fedora box cannot mount /home at bootup. I have to log in as root, and mount it over command line.
-Googling for the error it gives at bootup doesn't give help, as systemd doesn't have the same amount of answers to previous questions as older systems have.

The point is, I cannot blame systemd for this. I should RTFM. As soon as I find it. And have time for it.
Reading bash scripts is much easier.

No.

[waspleg]

I just installed Linux Mint 17.1 Cinnamon (Rebecca release) on the machine I'm typing from this week. While it does have some things I don't like (some weird config location choices, /var/run, /etc/bash.bashrc, bash_completiond,WTF is up with dnsmasq?, some weird sound behavior, semi-broken bash tab completion, won't mount my cellphone no matter what, etc - aka issues I've never had with CentOS).

I also still have 2 several years old but up to date CentOS boxes I use every day and prefer them but I picked Mint because it's supposed to be better for day to day regular desktop use, has far more up to date packages, and I was tired of fighting dependency hell with extra packages from 2008 (my own fault, admittedly) for things like VLC.

My understanding, and I can't find where I read it before I went and downloaded/installed it, is that Mint is in wait-and-see mode and will be waiting until their next LTS release in a few years and then re-evaluating whether to switch to systemd. Looking at the system I have installed right now, it looks like there are a few pieces installed for compatibility (although none of them are running) but the init system is still old school init.d and runlevels.

I haven't looked at systemd in depth but my gut feeling is it throws away the UNIX mindset of, do one thing and do it well, output/input everything in text in favor of aping Apple (paritcularly)/Microsoft and the politics behind it seem dirty. I have watched a few Poettering videos and he comes off as a massively arrogant douche bag (but I am a fan of Linus and RMS so *shrug*).

$.02

Re:ABOUT FUCKING TIME!

[Anonymous Coward]

What you say is very true. IMHO Ubuntu has become an answer but someone that forgotten the question.
I lost faith with it around the 2012.4 release. Far too much essential stuff unfinished.
Went back to Debian for a while but a new job in 2013 has given me an insight into the RedHat world. now I run CentOS on my laptop. Rock solid.

However if you want nowt to do with 'systemd' then there is very little choice left. Even Debian has gone to the dark side.
BSD? Off you go then.

Personally, I think that Ubuntu is becoming increasinly irrelevant with each release.

Re:ABOUT FUCKING TIME!

[Anonymous Coward]

systemd is actually pretty kool. I mean, except for running Windows, how else could
you introduce subtle regressions into linux?

The LUKs wait for password at boot timeout is back again; policy kit thinks I need root
permission to mount devices already mounted, etc.

There are other regressions,too, but you just get used to them :(

Why systemd took over

[jbernardo]

There are several main reason why systemd has overrun some of the best known distros. On of the biggest is simple. Gnome depends on it, and soon KDE will too. Distro maintainers either bend over for systemd, or will spend a lot of time patching and trying to get these two desktops working on GNU/Linux.

Then, you have two types of distro maintainers. Volunteers, and paid developers. Volunteers are guys like you and me, with limited time to help, doing things on spare time. Paid developers usually are RedHat or Canonical employees (we also had novell employees when they destroyed SuSE), and the first seem to be more and with more money to spend on pushing RedHat technologies. Unpaid volunteers can't even compete with the deluge of code and the sponsored conferences and presentations. Any alternative or dissenting voice is either bought or pressured to give up.

Finally, some claim that systemd solves a lot of things that didn't work, and that if you don't know what these are then you are an idiot, as obviously Linux has never worked well in the last 20 years.

But what do I know, I've been told enough times that I am heretic (hater in doubleplusgood newspeak) for daring to criticise systemd.

Re:Watching systemd evolve

[gweihir]

Systemd causes log corruption where sane alternatives do not have such issues. Ever wonder why?

Re:ABOUT FUCKING TIME!

[DoofusOfDeath]

I'm thinking of a few specific aspects of how the ACA passage happened.

The first is Pelosi actually convincing members of Congress to vote on the bill before reading it. I.e., her infamous "you'll have to pass the bill to find out what's in it" gambit. (It takes a lot of self control to not go into a tirade every time I think of that.)

The second is this: NPR did a great story talking about a variety of healthcare systems around the world, in terms of cost, outcomes, and implementation details. (Germany's looked especially good.) But nothing in the ACA seemed to indicate any of those vetted designs was seriously considered. It's like the authors of the ACA suffered from Not Invented Here syndrome. Or perhaps just as likely, the lobbyists didn't find it to their liking.