Slashdot Mirror


Debian To Replace SysVinit, Switch To Systemd Or Upstart

An anonymous reader writes "Debian has been one of the last holdouts using SysVinit over a modern init system, but now after much discussion amongst Debian developers, they are deciding whether to support systemd or Upstart as their default init system. The Debian technical committee has been asked to vote on which init system to use, which could swing in favor of using Upstart due to the Canonical bias present on the committee."

8 of 362 comments (clear)

  1. Re:Ugh by lasermike026 · · Score: 5, Interesting

    Yeah, SysVinit is not only fine but preferable. It's simple and effective. I see no reason to change.

  2. How about OpenRC? by Anonymous Coward · · Score: 4, Interesting

    Why not keep sysvinit and switch to OpenRC for managing the init scripts?

  3. I've got OpenRC installed... by Anonymous Coward · · Score: 5, Interesting

    On a Gentoo box, and it should still be starting via sysvinit.

    My #1 reason for keeping it installed is standardization:
    All the BSDs use a similiar system, all the legacy UNIXes do as well, as do all my linux installs that are more than 2 years old.

    Additionally I have had *NO* problems with it in like 15 years that weren't caused by user error, or distro error. Systemd on the other hand rendered my system hung or inoperable on more than a few occasions when it first became popular, as has udev by itself. There's something to be said for 'windows-like' functionality, but all the subsystems that have been getting added to linux to provide it are proving messy, unmaintainable, and even more prone to 'unidirectional grading' (it used to be you could have both newer and older kernels, even across major versions running. Nowadays you're lucky if the minor versions don't break things over the span of two months. Anyone here remember having 1.2 installs running 2.0? Or 2.0 with a 2.2 kernel? Or 2.2/2.4? The only major issues you had were if you used ipchains/tables/ipfwadm and had to migrate your settings. And there was almost always legacy support for most or all of a major version change.)

    Honestly with the way linux is going nowadays, as well as the various *BSDs, I'm considering very strongly migrating to another platform. If you change what people are used to too much, there's far far FAR less incentive for them not to try something totally new rather than bungling themselves up with half remembered details about how their *FORMER* version of the system operates. Much like happened with WinXP/Vista/7/8.)

    Not that many people will agree with this assessment.

  4. Re:Go home Debian, you're obviously drunk by Rich0 · · Score: 5, Interesting

    The problem with sysvinit is that 95% of daemons just need a common set of actions to start/stop them, and sysvinit tend to handle this by writing bash scripts starting from a skeleton.

    So maybe for one daemon you can set a config setting to make it use ionice, and for another you can't, simply because in one script a bit of extra functionality was written.

    For the most part systemd makes a config file into a config file, not an executable. Sure, you can run a script if you have to, but 99% of the time you don't need to.

    In fact, there is no reason you couldn't write a sysvinit script that takes in a systemd unit as a config file and starts/stops the corresponding service. That would be a great way to transition - switch your bash scripts to unit files gradually and then swap out the init system.

  5. Finally! by cpicon92 · · Score: 4, Interesting

    It seems like I'm the only person on here who thinks this, but I really can't wait for the switch to happen. Upstart scripts are unbelievably easy to write when compared with init scripts. For one thing, they don't require massive amounts of boilerplate code. For another, they are relatively easy to manage and execute.

    Just the other day I was trying to set up a couple of machines running deluge as a daemon. The Ubuntu machines took me 10 minutes tops. The remaining debian one had me in init script hell for an hour or more...

  6. Re:Uh... by Chemisor · · Score: 5, Interesting

    That sounds retarded. Why would anyone wanna change to that?

    We want to change to "that" because basic idea is a good one. The ability to start services in parallel, socket activation, and cgroups for process group management are all good things. The problem with systemd is not so much these ideas, but the implementation. To put it bluntly, the developers are all "superstar" jerks who wouldn't know usability if it hit them over the head.

    They designed an ugly interface with way too much automatic magic that no doubt is perfectly obvious and correct to them, but abstruse and incomprehensible to anybody outside their little circle. Then they wrote a couple of "howto" articles on complex sysadmin tasks that almost nobody has to do, and declared documentation complete. To do a simple task, like writing a service file, or God forbid, changing the getty program you want to use, requires a monumental effort of sifting through disconnected, unintuitively named man pages.

    systemd: good idea, horrible implementation.

  7. Re:Go home Debian, you're obviously drunk by whois · · Score: 4, Interesting

    Debian has a habit of not using things until they work. I expect they would fix most of the issues or they wouldn't ship it.

  8. I'm Torn by Foresto · · Score: 4, Interesting

    After having repeatedly run into the limitations of SysV init, I'm all for replacing it with something smarter, but I'm torn between these two.

    I've used Upstart on Ubuntu, both as an admin and as a developer. I like that the commands and configuration files are clean and pretty easy to understand. A few things bother me, though:

    • The model of starting all dependent services when their dependencies start is backwards. I don't necessarily want init to launch every daemon under the sun the moment I mount their data filesystem. I'd rather have it mount the required filesystem when I ask for a particular daemon to start.
    • As of a year or so ago, the documentation was mainly an incomplete bunch of blog posts. Once I found them, it was pretty easy to configure daemons that behaved like the venerable ones that are often used as examples, but it was difficult to learn how to match Upstart's features (some of which are undocumented) and events (also largely undocumented) with an unusual service's behavior
    • Debugging was difficult, mainly because so few events are well documented and it's not always clear which of Upstart's features are implemented in in any given version. (I hear the latest release offers some event tracing tools that would improve this.)

    I haven't used Systemd at all, but the common points that come up again and again in every writeup I encounter have me forming me some opinions already. I really like the idea of the load-as-needed dependency model. A few things have me quite worried about the implementation, though:

    • Configuration is reportedly difficult to understand. That always leads to frustrating, time-wasting, messy problems.
    • The code is reportly rather complex. That usually leads to chronically buggy software, which is not what I want in a process as important as init. It also tends to hamper portability, which could make Systemd a poor candidate for replacing init on other unixes, which would relegate it to being yet another OS-specific hassle for coders and admins all over the world. I'd prefer something that could reasonably be adopted everywhere, or at least by most of the operating systems I have to administer, even if a few features weren't available on every platform
    • I recently learned that the guy behind Systemd is the same guy who brought us PulseAudio. I don't want to get off topic here, but this gives me little hope that Systemd will ever work well outside the lead developers' development machines. (Pulse is around 10 years old now, and every time I give it another chance, it proves itself intolerable.)