Ubuntu To Switch To systemd

Good...? by Kagetsuki · 2014-02-14 04:39 · Score: 5, Insightful

I think it's good Shuttleworth was able to suck up his pride and go along with this decision to prevent fragmentation. I do however call the original decision slightly into question, but that's only because I've gotten sort of used to upstart. Hopefully anything good that was implemented in upstart but was not in systemd will make its way over.

Re:Good...? by fishybell · 2014-02-14 04:53 · Score: 5, Insightful

Having switched from System V to upstart to systemd I can safely say that yes, systemd is better for a full server or desktop OS. It has better reporting tools, it has more fine grained control, and it's fast. The trade off is complexity and size. There are many computer systems that the cost of switching to systemd will not bear fruit for a very long time (ex. embedded), but for servers and desktops that time has arrived.
Learn to love systemd; it's here to stay and for good reason.

--
><));>
Re:Good...? by fishybell · 2014-02-14 05:30 · Score: 5, Informative

System V has a scrict sense of a run level. For example, if you want a full desktop, run level 5 is often used, for a headless server, run level 3. What if you have a box that is headless most of the time, but you want to be able to run a full desktop sometimes? With System V you would change from run level 3 to run level 5 which would, depending on implimentation, stop and start services that are needed by both. Systemd instead has the concept of targets. Your full desktop target would have the headless server target as a dependency, and starting the full desktop would only run what isn't already running. You typically also have individual sevices that have dependencies. For example, you'd want your dhcp server to wait to start until the network has come online. In System V you have to define network as a number and make sure everything that depends on it has a bigger number and everything it depends on to have a smaller number. systemd's dependency model is also smart enough to start processes in parallel.
All of that is just the most exposed part of systemd (to me at least). It also supplants other processes such as xinetd and udev. Instead of having three different ways to start processes based on system events (startup, port connection, hardware event) you have a single system to manage all three. It can get complicated (wasn't udev already complicated?) but the consistency is worth it.
To keep all the consitency systemd provides a series of functions and magic variables. By magic variables I mean you set a list dependencies, which IMHO is less magic than the chkconfig comment lines in a typical System V init script. Both the magic variables and functions mean your typical service initaliation script is 10 lines instead of 100. While they may not be as obvious what's going on (a System V script is self-contained and can be ran on it's own) it is once you've become familiar with them.

--
><));>
Re:Good...? by Billly+Gates · 2014-02-14 07:07 · Score: 4, Insightful

The bad is is SysV not event driven.
This might be ok for servers but lets say you have a laptop with Ubuntu. You are on a network and it goes to sleep at work. You grab it and head to the airport for a trip and the laptop wakes up elsewhere. All of your SYSV scripts to do things like pass settings to daemons relating to network and Samba get messed up.
With an event driven system you tell it to do things based on conditions or events such as your laptop going to sleep and waking up on a different network as an example. You can use SystemD to re-initialize itself not just on startup but when things happen with this new ability. A hacking attempt on a server, an unplanned reboot, or anything else
The bad about SystemD compared to upstart and Apple's or Sun's event driven systems:
- no text files
- binary reporting
- quite complicated compared to other event driven systems like the older upstart
System admins hate systemD as it does not follow the Unix philosophy of text files and now awk, sed, grep, or perl to batch jobs :-(
Some also is resistance to change as many unix old timers hated anything new by Sun and did not want to relearn writing new scripts all over again. But, this tries to solve a problem like the laptop example but at the cost of complexity and non integration.

--
http://saveie6.com/
Re:Good...? by amorsen · 2014-02-14 07:25 · Score: 5, Informative

Indeed, journalctl is probably what I dislike the most about the current systemd stack. For one thing it is slow with full text search in large log files -- it is reasonably fast if you use the built-in column-specific search, but just running fgrep on it is not really feasible. In contrast, fgrep is ridiculously fast on modern systems as long as your log files stay below a few gigabytes in size. Also, the output of journalctl changes (mostly for the better) when you use it with pipes, which can be quite surprising.
The other major problem with systemd is how difficult it is to debug boot failures. It is quite annoying when an fstab which was correct with upstart results in silent boot failure with systemd.

--
Finally! A year of moderation! Ready for 2019?
Re:Good...? by Bacon+Bits · 2014-02-14 07:35 · Score: 4, Interesting

Yes, and you have to understand that that only works because your DE of choice has bent over backwards to make sure all it's dependencies are running and functional when you try to start it. That is to say, startx has to duplicate functionality of init because init is too stupid or too unreliable to be able to do it for your DE.
This issue can be generalized to any significantly complex application. That means you already have a half dozen "init systems" working on your systems. They're all independent (even though they maybe should know about each other), and you can't manage them universally (even though you might want to fire things off with system level events, like restarting a service if it crashes), and you certainly can't be sure you're not stepping on each others' toes.
Essentially: a large enough number of people noticed that the same features for starting and managing processes were getting implemented over, and over, and over. They realized that these functions belong in the init role -- because only init has the authority and knowledge required to not screw it up -- but that sysv-init didn't have the capability to do any of that.
All this began to happen perhaps 10 years ago, when other operating systems (e.g., Windows, which has had service dependencies and crash recovery since Windows 2000) showed what a more feature-complete init system was capable of.
At this point these "why do we even need a new init system?" questions are like someone watching I-40 getting repaved in the 1970s and asking "why do we even need Interstates?"

--
The road to tyranny has always been paved with claims of necessity.

Re:Whats wrong with init? by EmperorArthur · 2014-02-14 05:04 · Score: 5, Interesting

Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.

I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.

In the end, I just really like the ease of use of service files. Oh, and the stupidly fast boot time on my laptop is really nice. People who say boot times don't matter aren't living in the real world.

--
So lets pretend that we've just completed writing this code, as opposed to having just completed sabotaging it -Altera

Re:Whats wrong with init? by causality · 2014-02-14 05:06 · Score: 5, Interesting

"I know nothing about this software but I'm gonna bitch, complain and sling shit at it anyway. How dare they move my cheese!"

- Typical Slashtard

Knowledge of the new software is a separate (easier to cheaply ridicule, stay classy) question. The issue with systemd: it reeks of a solution looking for a problem.

If the existing init systems were causing widespread grief I'd be much more receptive to it. So would just about anyone currently questioning systemd's rapid adoption. Right now the reason for installing it is "everyone else is adopting it as the new standard and it will be increasingly difficult to go against that standard." That's not the best of selling points. It's not like "wow all these problems and limitations I had been experiencing will finally go away!" like you get with truly sensible and evolutionary changes.

If you think that shouldn't matter to anyone, you could explain why you think so. In the meantime, please make an effort to understand the viewpoint of those who disagree with you. Then you stand a real chance of actually addressing the issue, or at least of not embarassing yourself with smug hand-waving and knee-jerk dismissals based on your annoyance that everyone doesn't already agree with you.

--
It is a miracle that curiosity survives formal education. - Einstein

Re:I agree by ZarathustraDK · 2014-02-14 05:06 · Score: 4, Interesting

Your comment made me switch back to Ubuntu. Seems like all the tinfoil-whiners are gone from there now.

--
If you quote this signature there'll be 72 copies of Windows ME waiting for you in Heaven.

systemd violates the UNIX philosophy by bzipitidoo · 2014-02-14 05:12 · Score: 4, Insightful

The philosophy of modularity. Tools are many and small and simple, do one thing and do it well. But then, the Linux kernel also violates this principle.

There's also this seeming drive to make more tools dependent on systemd. Does udev really need to depend on systemd?

Wayland may be an example of an approach more in line with the UNIX philosophy. X has a lot of baggage that has become useless over the years. Lot of basic graphics functionality has moved into specialized graphics hardware.

--
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"

Re:systemd violates the UNIX philosophy by joejor · 2014-02-14 05:26 · Score: 4, Informative

Here's a pretty good treatise on the shortcomings of systemd: http://ewontfix.com/14/

Re:like conceeding that air is necessary by raxx7 · 2014-02-14 05:14 · Score: 4, Insightful

Users rightfully do not care about what init system they use, as long as it works.
But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said.
Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian.
GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

And that means they can actually spend time fixing other stuff.

why not the new thing? by dAzED1 · 2014-02-14 05:20 · Score: 5, Insightful

There's this new thing called "init.d" which makes things really simple - you can start a system up and step through things, and though the boot takes 5 seconds instead of 1 second, that isn't really a problem.

Once I read the original post about systemd, and all the other let's-invent-a-problem-to-fix nonsense surrounding init.d, I literally hung up my hat and stopped being a syseng. I was a unix guy starting in 93, so it was probably time anyway, but it was the straw that broke my back, as it were.As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. I especially "loved" this line: As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. No. A good init system does it reliably, with no drama and no politics. A good init system allows one to easily determine the state of a system, and doesn't assume things like GUIs and such. A good unix init system does all this with commands which can be piped and parsed easily with grep and awk - two things the original post about systemd actually complains about. The idea that a unix person would complain about grep and awk was so mind-boggling to me that...well, I just hung up the hat. You did all this nonsense, just to save a few seconds? Because what, the only thing linux is used for, is laptops? Meh.

Re:why not the new thing? by broken_chaos · 2014-02-14 05:59 · Score: 4, Informative

If a daemon has problems and needs to restart itself how does it do that?
...Monit? runit? Two completely different approaches to service monitoring, one not even in an init system. And there are more (s6, daemontools, etc.).

hundreds or thousands of daemons
...What the heck are you running that puts thousands of daemons on a single server? If you're doing something this large, you might want to consider virtualization. Thousands of daemons is a gigantic attack surface to have on a single system, and a mess if something were to go wrong with one of them that takes down everything.

Re:Why I don't like systemd: by Anonymous Coward · 2014-02-14 05:23 · Score: 4, Informative

put this line in your .bashrc file

alias service='systemctl'

Re:Embedded uses something different anyway by dalias · 2014-02-14 05:24 · Score: 5, Insightful

This is a fallacy. A shell script running on a non-bloated shell (e.g. Busybox ash) consumes less than 50k of dirty pages per instance. It would take at least 20-30 such scripts running to even come close to rivaling systemd's memory usage, and that's not even counting other resources systemd is consuming.

Re:Embedded uses something different anyway by Anonymous Coward · 2014-02-14 05:34 · Score: 5, Informative

I don't think very much embedded stuff will ever use systemd..

I am using Angstrom, which uses systemd, for embedded stuff. Haven't had any problems with systemd, but haven't tried to do anything complex either. It gets stuff started at startup time, that's all I have needed.

Re: by binarylarry · 2014-02-14 05:48 · Score: 5, Funny

Well fuck it, lets rewrite the Linux kernel in bash!

--
Mod me down, my New Earth Global Warmingist friends!

Re:Whats wrong with init? by tlhIngan · 2014-02-14 05:49 · Score: 5, Interesting

Lets face it, sysV init is complicated. Well, the theory behind the old linear start from init script 00 and move to init script 99 isn't, but the modern implementations and the scripts themselves are complicated. I mean you're doing dependency checking and a whole bunch of other things in bash scripts. Compare that to a systemd service file, which is overall nice and readable. So, part of it is factoring out the logic from the variables. The other big thing is bash and the tools used by init scripts are like using a sledgehammer to tap in a finishing nail.
I'm not going to say that systemd is perfect. I like the "unix" way which is to use small units that do one thing well instead of anything. That's part of the reason I see bash init scripts as too much for the job. Unfortunately, the systemd authors look like they want to throw in everything but the kitchen sink. Well, everything that they can't just port to kernel space that is. But that's the thing, Linux is a Monolithic kernel. Like it or not, the "Linux" way is to have one uber optimized thing with modules to handle everything.

Well, the BIG problem is maintenance. SysV scripts have both a S and K variant on when to run when switching levels, and you can bet very few people have it properly set up if you do switch levels. Enough so that switching levels is fraught with danger - you can probably start at level 1 (single user), and switch to 3, 4, or 5. Maybe you can get back to 1 because the extra demons get killed. Maybe.

In the end, it's bit of a maintenance hassle, and while completely understandable, it's a nightmare.

In fact, I'm guessing most utilities don't even bother handling the case - you just reboot and forget about it.

After all, computers are good at doing stuff automatically - so stuff like maintaining which services should run at which runlevels should be automated - the init can figure out what it needs to start, what it needs to kill and the order based on dependencies. All the user needs to do is select what needs to run at what runlevel, and the tool does the rest.

Then there are the various hacks to SysV - PID files (if so many tools need to know the daemon PID, why not have init actually do that work than requiring every script to do it manually?), the fact that state tracking isn't really in the system, and if you need services to relaunch on failure within limits, there ought to be a way to do it without requiring a trip to /etc/inittab to specify that fact.

Nuts, upstart syntax is so easy by exabrial · 2014-02-14 06:17 · Score: 4, Insightful

I really like upstart. The scripts are stupidly easy to write and understand, and the syntax is plain english.

Actually that's the only reason I like upstart. Maybe with Ubuntu onboard with systemd we can get an alternate, easier-to-use syntax than the default systemd.

Re:Sigh. by caseih · 2014-02-14 06:37 · Score: 4, Interesting

Yes if you think systemd is bad, either rip it out on your machine or roll your own distro. Or move to FreeBSD. It's available now, and it runs great. So no need to whine. Just move to an operating system that fits your personal parameters. More likely you'll stick with your current distro and whine and moan about something that you don't well understand.

On the desktop side of things, I've been watching Linux struggle for years to do simple things like deal with removable media and USB devices. For a while there was hal, then udev, and now systemd. And finally things are actually working, and working rather well. Mostly thanks to udev, but systemd now builds on that. I know many people don't mind manually mounting devices and loading modules to make usb devices work (I don't mind, really). But it's nice to have things automatically work.

And really systemd on the service isn't that bad an idea either. Fine-grained logging is very useful and conventional syslog is still available and will always be there. Process supervision is something that's been needed for a long while now.

Re:Whats wrong with init? by nabsltd · 2014-02-14 07:38 · Score: 4, Informative

In the end, yes, it's another config language you'll have to learn, but it's worth it.

Why is it worth it?

I've heard lots of "systemd is better" claims, but not one real-world example of how it took 27 hours to debug a startup issue when using SysV, but only 13 seconds using systemd. And, I really don't care about boot times, because my physical servers take 10 times as long running through BIOS checks as they do going from grub load to system ready. Even VMs don't matter much, as they don't get rebooted very often, so saving 5 seconds on a 30-second boot time isn't really a big deal.

On the other hand, I've heard lots of stories from people who have to install a custom service (i.e., not from a "apt-get" or "yum install") on a systemd system and complain about how it took hours to get the dependencies right.

Re: by nicolastheadept · 2014-02-14 07:46 · Score: 4, Funny

The truth is I never loved you

--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re:Stupidity is contagious by fgodfrey · 2014-02-14 08:55 · Score: 4, Interesting

The distros are going with it presumably because they think they need it to turn Linux into a desktop or notebook OS. However, they seem to be ignoring the issues it presents for servers. Let's take my *THREE HOUR* debugging session on systemd yesterday. I had a netboot system up and running. Client boots from Server and mounts root filesystem from Server. I changed from Server A to Server B. Due to an NFSv4 vs. NFSv3 issue, Client could no longer mount the root filesystem read/write. Simple, right? It would've been with SysV init because the errors during the mount would've been spewed to the console and I would've seen them. What *actually* happened is that a bunch of services failed to start. Instead of spewing the error message, systemd "helpfully" told me to run "systemctl status" on the service to see the error message. Except that I never got to a login prompt due to the errors. And I couldn't mount the filesystem read/write so it lost the logs.

Two+ hours later, I managed to disable enough stuff to get to a login prompt where I was finally able to figure out what was going on (never did get systemctl to show me the logs, probably because they couldn't be written to disk and it doesn't seem to hold them in RAM).

Please explain to me what the advantage of systemd is again? Because I'm *REALLY* not seeing it. It took something that was trivial to figure out and made it astronomically difficult. I no longer have any idea what order my services start in or whether that order is repeatable. Yes, SysV init scripts were really long. But once you learned them, you realized that you only had to modify 5 or 6 lines of them to get a new service going. I have yet to figure out how to even create a service with systemd or how I figure out what I'm depending on.

In short, for a server, I have yet to see a single advantage of systemd over SysV init. Maybe I'm missing something and someone will enlighten me, but I'm extremely skeptical.

Am I just resistant to learning new things? Maybe, but learning stuff takes time and my time is money for my employer. So if I'm not getting a return on my investment of time (in new capabilities or reduced debugging time or *something*), why would I invest the time to become an expert on systemd?

--
Go Badgers! -- #include "std/disclaimer.h"

24 of 279 comments (clear)