Slashdot Mirror

← Back to Stories (view on slashdot.org)

Debian To Replace SysVinit, Switch To Systemd Or Upstart

Posted by samzenpus on from the changing-it-up dept.

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."

45 of 362 comments (clear)

  1. Canonical might suck... by GameboyRMH · · Score: 3, Interesting

    But that doesn't mean that Upstart does.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
    1. Re:Canonical might suck... by Anonymous Coward · · Score: 3, Interesting

      Yea who doesn't want their DB servers kill -9'd if they take too long to shutdown. Hooray upstart.

    2. Re:Canonical might suck... by TheCarp · · Score: 3, Interesting

      Well my first thought on this was.....its a smart move for desktops, but I intend to continue using sysvinit on servers for a long long time to come.

      --
      "I opened my eyes, and everything went dark again"
    3. Re:Canonical might suck... by heson · · Score: 4, Insightful

      Upstars solves some problems with sysv, but includes a whole array of new ones. Systemd solves almost all problems with few new ones, except for all the parts that is not implemented yet. Systemd is a mess for novices to use and understand, the helper tools are not as good as they should be.

    4. Re:Canonical might suck... by jones_supa · · Score: 4, Funny

      mostly okay for some stuff, and utter **** for anything else.

      So mostly okay for some stuff, and four stars out of five for anything else? Pretty good, pretty good.

    5. Re:Canonical might suck... by icebike · · Score: 4, Insightful

      This is very true.

      Like much in the linux world these days, systemd was rushed into production before it was half completed by too many distros.
      At least you have to give Debian the credit for waiting until most of it is working, and all the necessary patches have been identified.

      (The less charitable way of viewing it is that Debian sat back and let others do the heavy lifting).

      Probably the worst case would be for them to choose upstart when the rest of the industry decides on systemd. That kind of divergence
      makes for much more work patching everything that needs to be patched.

      --
      Sig Battery depleted. Reverting to safe mode.
    6. Re:Canonical might suck... by fatphil · · Score: 3, Insightful

      Indeed, Canonical sucking *doesn't* mean that Upstart sucks.
      It's the fact that Upstart sucks which means that Upstart sucks.

      At least from an embedded perspective (which is the majority of linux systems) the system should start only that which is necessary rather than everything that is possible. It also suffers from the classic stampede mistake when it becomes possible to start a whole load of new services after a shared dependency is started.

      --
      Also FatPhil on SoylentNews, id 863
    7. Re:Canonical might suck... by dshk · · Score: 3, Interesting

      Upstart was already in a good shape when SystemD started. So if you consider this fragmentisation because of this, then please note that in this case it is not Ubuntu who fragments Linux distros, quite the opposite... Personally I find writing Upstart configuration files trivial. On the other hand I have never been able to write a perfect System V script. I hadn't found comprehensive documentation about it (especially about the various helper scripts and config files frequently used in init scripts). On the other hand, if you read the Upstart doc, which is a single long HTML page, at most 1 hour to read, your will know everything about it, much more than what you will ever use. I have not tried SystemD, so I have no opinion on that.

    8. Re:Canonical might suck... by Junta · · Score: 4, Insightful

      So one prominent example is a push to discard syslog, but at the same time rejecting any suggestion that perhaps it might be nice if the same plain text that journalctl can produce be produced as a matter of course without syslog assistance.

      Yes, journalctl has more readily accessible nice filters and faster performance. The issue is that the vast majority of people didn't ever need them and made due with grep and friends. Yes it's not good stuff to build a high-end solution out of, but by the same token journalctl power is more complicated to use.

      Getting early boot messages would have been a straightforward thing to do in syslog land, it was just that no one bothered. It was a good thing to add, but generally either things work fine and you don't really care much about the early boot logs, or it fails to get root fs going in which case the logs from that time won't make it to the root fs hosted journal anyway.

      I don't like the linux distros of today because they are largely reimplementing much of what people ridiculed microsoft for in the 90s (binary configuration, binary logs, more complex messaging model). While it is true that generally the details of the implementation are defensibly better than microsoft did, the differences are largely academic to the vast majority of system administrators. Vast majority sees opaque binary blob that is useless without a very close match in distribution to provide tools to analyze. Even when things are humming along fine, things like dbus provide capability in a nearly impossible to explore manner. Even with all this complexity, my linux server experience is no more useful than it was 10 years ago from a managability standpoint, but I've had to jump through hoops to try to track the complexity as it emerged bit by bit without a lot of nice capability to come along for the ride.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    9. Re:Canonical might suck... by Grishnakh · · Score: 3, Insightful

      Why not just make the journal in a standardized format, that can be read by any other system? If I need to look inside a .zip or .tar.gz file, I don't need tools on a specific computer to do that; I can copy those files to any computer and look at them with zip/unzip or tar/gzip. Why should it be any different with systemd logfiles? You shouldn't need to use the computer that generated those files to read the files, just the same tool on another computer. If that's a problem, then there's a serious failure in implementation.

  2. Ugh by ArchieBunker · · Score: 4, Insightful

    I fucking hate this new system. Its a mess of scripts that call on more scripts. Its such a pain in the ass now if you want to have a program run when the system starts. Gone are the days of just adding a line to /etc/rc.local

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
    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. Re:Ugh by MightyMartian · · Score: 3, Funny

      I'm with this too. Fuck Canonical. They have become a real pain in the ass, and worst of all, they're a pack of fucking retarded assholes. I can't say it enough. Fuck Canonical. Fuck Canonical. Fuck Canonical.

      Debian is one of the best distros out there, let's not allow the fuckwaddery that is Canonical and their arrogance and intense stupidity ruin it. The current init system works just fine.

      Oh, and in case you didn't get it. Fuck Canonical. Fuck Canonical. Fuck Canonical.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    3. Re:Ugh by Arker · · Score: 4, Informative

      Slackware still uses sensible init scripts you know.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    4. Re:Ugh by Tanktalus · · Score: 5, Funny

      I really wish you'd get off the fence and pick a position on the issue.

    5. Re:Ugh by icebike · · Score: 4, Insightful

      I fucking hate this new system. Its a mess of scripts that call on more scripts. Its such a pain in the ass now if you want to have a program run when the system starts. Gone are the days of just adding a line to /etc/rc.local

      Half of that is because either SystemD or upstart is really only about half implemented, and the half that is implemented is often trying to replicate sysv just to keep the conversion and learning task to something approaching manageable. Its kind of a mess right now in many distros.

      As more of the system targets are properly implemented, and users start to let go of the concept of run levels, and get used to dealing with target files and the concept of units, it will be every bit as tailor-able as run levels were, and a whole lot faster.

      I didn't find run levels and rc.d all that intuitive at first (many long years ago) and the scripts were more complex.

      --
      Sig Battery depleted. Reverting to safe mode.
    6. Re:Ugh by thrift24 · · Score: 3, Informative

      It sounds like you are describing the current system, not the new system. And if you don't like the current system, you are going to hate the new system.

      What I would consider the old system would be something like SlackWare(RC scripts) where the system might have 8 or 9 different shell scripts called during the boot process, but it's essentially one giant autoexec.bat. Simple to make modifications to the boot process, but installing new services or upgrading the system may require manual merges and break your installation.

      The current system is more like RedHat/SuSE/debian(Tradtitional init), where there are tons of scripts that call other scripts and it gets pretty complicated, but for the most part everything is a script and can be easily traced. This is more difficult for the inexperienced to modify, but is reasonable for those familiar with scripting and is great for adding new services and upgrading the OS. Basically the scope of a change is smaller, so less stuff breaks.

      The new system is something like Fedora/Ubuntu(Systemd/Upstart). There are config files for everything from services, to devices, to sockets that are parsed by a binary that isn't very open to inspection. This leads to a very fast boot up and has neat features like the ability to view the logs of a service with the same command used to start it, but is also like sticking your dick in a box of razers, because when something goes wrong you can't just pull out vi and look at the logic being used to boot the machine. It also leads to somewhat unsettling things like a merged /usr and a /run.

      To be fair this might be somewhat unfair to Ubuntu, because I haven't invested much time into Upstart. If it was something worth looking at I'm sure the Fedora/SUSE devs would have dropped systemd for it though.

      What would be really nice is if Debian built a version of systemd that didn't have a big binary core, or at least split the thing into several different services. I like the speed and slickness of systemd, but if anything goes wrong with a system using it, I will have no idea how to fix the thing -- and that's after using systemd on my primary laptop/server for over a year.

  3. Why keep making simple things complicated? by Arker · · Score: 4, Insightful

    Init would have been my pick, but I still hope this works out well for them.

    --
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Friends don't let friends enable ecmascript.
  4. How about OpenRC? by Anonymous Coward · · Score: 4, Interesting

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

  5. Re:Uh... by Chemisor · · Score: 5, Informative

    I fucking hate this new system. Its a mess of scripts that call on more scripts.

    Actually, that's how sysv init works. To get a program started by systemd you have to create a service file full of magic commands and put it in the magic systemd directory. Then you have to type systemctl --abracadabra enable yourservicename.service. Then you have to go and add an [install] section to your service file, because nobody actually remembers that you have to write one or how to do it. Then you do the systemctl again. Then you check the log files to see if the thing actually started, because nothing gets output to the console during boot (except the filesystem mount messages and the big fat warning that my root fs is readonly).

  6. sysvinit is dead; long live sysvinit!!! by helobugz · · Score: 3, Insightful

    Tell me I'm not the only one still clinging to sysvinit?

    The new "replacements" (alternatives) are ghey++ and will no doubt be replaced in due time.

    I dno't want to hear about a few seconds faster boot time. I want my *nix startup to be configurable, scripted, and simple. sysvinit takes the cake;.It's documented, and sysvinit is so simple it doesn't really require documentation, anyway.

  7. Really? by prefec2 · · Score: 3, Interesting

    This is your way of stating your opinion? Looks, like your parents forgot to teach you something particular important to be considered an adult and able to participate in a discussion. You could say that you disagree with Canonicals decision towards Wayland/Weston. You could say that the way they handled the issue and announced Mir sucks and was not a cooperative mode. In addition they made some bad blood. And that all would sound like someone really discussing the issue, but really you just sound like someone either too young to remember the vi vs. emacs wars or like someone exhumed from that day, just to behave like a troll.

    BTW: Get a life, normally that reduced these urges to hate someone just because you find his or her decision questionable.

    1. Re:Really? by jedidiah · · Score: 3, Interesting

      It's far too easy to shoot yourself in the foot with upstart. It is much more complicated. In it's efforts to solve a non-problem (namely making a machine boot faster) it tries to do things in parallel and creates a web of dependencies that can render your system unbootable.

      It adds extra complexity for dubious gain.

      It's the perfect example of why we shouldn't necessarily accept the advice of "helpful types" that think that things should be done the way that Microsoft does it or the way Apple does it.

      --
      A Pirate and a Puritan look the same on a balance sheet.
  8. systemd - bad & getting worse by Anonymous Coward · · Score: 3, Interesting

    I used to not only use RedHat, but contributed fixes. Ubuntu is not, in many respects, my ideal, but systemd is enough reason all by itself for me to use Ubuntu.

  9. Go home Debian, you're obviously drunk by sl4shd0rk · · Score: 3, Interesting

    SysV init scripts just work. They are simple to create and easy to maintain. Debugging is a cinch when things go wrong -- and a lot of packages DO NOT get upstart init, nor SysV init correct. Upstart is only easier in theory. In practice it's made a complete mess of things and I have several Ubuntu systems to prove it.

    --
    Join the Slashcott! Feb 10 thru Feb 17!
    1. 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.

    2. 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.

  10. 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.

    1. Re:I've got OpenRC installed... by hson · · Score: 3, Informative

      IMHO NetBSD's rc-system works really well here (Used by FreeBSD nowadays too).
      Simple and effective - and no symlinks all over the place like in SysV. It automagically orders services. If foo needs bar bar is started before foo.
      And I see now that it is what OpenRC is... or atleast was.

  11. "the Canonical bias present on the committee" by shallot · · Score: 3, Insightful

    Citation needed, anonymous. When has the Debian Technical Committee last made a decision based on a political bias?

    1. Re:"the Canonical bias present on the committee" by kthreadd · · Score: 3, Informative

      What do you mean by Iceweasel? That name change came because Mozilla actively asked Debian to do it, so they did.

  12. 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...

  13. 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.

  14. Upstart by intangible · · Score: 4, Insightful

    So upstart has some things that need to be fixed (mostly the clean shutdown thing)...
    Systemd is a monster that gets to infect more of you packages over time, plus you get the benefit of binary log files!

    I hope they choose upstart and just fix it up a bit.

    OpenRC has been proposed by some too, which seems like a nice sysvinit replacement, but event driven startup and shutdown of services (think laptops and hotswap stuff) is more important than just a fast startup time.

  15. None too soon! by redelm · · Score: 3, Interesting

    I cannot abide the SysV (AT&T) mess'o'symlinks multiple-indirect startup scripts. One reason I've stuck with Slackware for almost 20 years. It uses BSD-style inits that have far less indirection and need far fewer lookups. Frankly, some of the BusyBox startup look attractive too -- one script to rule them all :)

  16. Hoping for systemd by devent · · Score: 5, Informative

    I hope for systemd; I know it from Fedora. And in my opinion upstart is some kind of mess; it's a mixture of bash script and their own added syntax. It kind of feels like Microsoft's extensions for C++. I'm also a fan of declarative configuration like systemd is. After 5 minutes reading the manual of systemd I could write my own service for pdnsd.

    [Unit]
    Description=PDNSD
    ConditionPathIsMountPoint=/mnt/read
    After=NetworkManager.service

    [Service]
    Type=forking
    ExecStart=/usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
    PIDFile=/var/run/pdnsd.pid

    [Install]
    WantedBy=multi-user.target

    # systemctl status pdnsd
    pdnsd.service - PDNSD
          Loaded: loaded (/usr/lib/systemd/user/pdnsd.service)
          Active: active (running) since Mon 2013-10-28 18:46:23 CET; 1h 14min ago
        Process: 1585 ExecStart=/usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid (code=exited, status=0/SUCCESS)
      Main PID: 1587 (pdnsd)
          CGroup: name=systemd:/system/pdnsd.service
                          1587 /usr/local/sbin/pdnsd --daemon -p /var/run/pdnsd.pid

    Oct 28 18:46:23 vostrotitan.localdomain systemd[1]: Starting PDNSD...
    Oct 28 18:46:23 vostrotitan.localdomain pdnsd[1587]: pdnsd-1.2.9a-par starting.
    Oct 28 18:46:23 vostrotitan.localdomain systemd[1]: Started PDNSD.

    --
    http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    1. Re:Hoping for systemd by dshk · · Score: 3, Interesting
      Here is an Upstart script copied directly from the minecraft server of my 11-year-old son:

      start on runlevel [2345]
      stop on runlevel [^2345]

      setuid attila
      setgid mc
      env LANG=en_US.UTF-8
      chdir /home/attila/minecraft

      exec java -client -Xms2500M -Xmx2510M -jar spigot.jar > /dev/null
      respawn

      And then:
      # start minecraft

      I cannot see a single line which requires documentation in order to understand it.

  17. Re:Uh... by 0racle · · Score: 4, Funny

    systemd: good idea, horrible implementation.

    No Solaris SMF was a good idea, systemd is what you get when someone looks at that idea and says "you know what, I can fuck that up."

    --
    "I use a Mac because I'm just better than you are."
  18. Re: Uh... by Anonymous Coward · · Score: 4, Funny

    To shutdown: yank the power cable.

    To reboot: yank the power cable, then plug it back in again. Then depress power button if necessary.

    Accompany either process by shouting the magic words "fuck it, it'll probably be fine".

  19. Re:Lennart Poettering explains why Upstartd is bad by Aguazul2 · · Score: 3, Insightful

    Wow, with such a superior, arrogant and manipulative attitude, I think it is time for Debian to write their own, or continue with what they have. I would have nothing to do with someone who has so little respect for anyone else's efforts, using FUD against other projects, and who is so obviously trying to lure people into his self-serving spider-web trap. Perhaps his vision is that systemd will be the one process to rule them all, my precioussssss... and then finally Linux will be all his. Run away!!!

  20. Debian did well to wait by coder111 · · Score: 4, Informative

    You need to remember that most of the time Debian is not about developing new stuff, it's primarily about PACKAGING and DISTRIBUTING existing stuff.

    From "package a bunch of software into an usable system" standpoint it is a smart decision to wait until the dust settles and things are tried and proven. Especially if you are producing system as stable as Debian Stable.

    --Coder

  21. Startup times are important by coder111 · · Score: 3, Insightful

    I do agree bootup times don't matter if you run a server. For a laptop, a tablet, a mobile, even a desktop that gets turned off startup times are important. For tablets, laptops and mobiles, they are VERY important.

    I agree that complexity is evil. I have no experience with systemd nor with upstart, so I cannot comment on them. However, dependency graph and parallel execution should not be THAT difficult or complex :-/

    --Coder

    1. Re:Startup times are important by Anonymous Coward · · Score: 3, Interesting

      Yes, complexity is evil, the problem is that sysv is complex (read: bash is complex) and running bash's init code hundreds (thousands?) of times and seeking all over disk eats lots of time.

      The solution therefore, is not to introduce something even uglier and more complex like Upstart or systemd, which STILL runs bash init code hundreds of times, and seeks all over disk, but now also adds megabytes of source code that one either has to audit or put blind faith in, even though both systems are empirically unreliable.

      The solution (which I use) is to have a program which generates C code, which does all of what init does in a few kb of source and a few more kb of binary, and recompile that each time you want to change what runs at startup. The solution to seeking all over disk (which is by far the bigger time sink), is to put everything that runs at startup in an initramfs, so it is read sequentially from disk at boot (which I do), or to add precaching to the filesystem, so you can mark files needed at boot, and have them stored sequentially on disk, and read by the kernel into iocache at startup (which I have not done).

      Another problem is that lots of programs create files on filesystem at startup, such as pid files, log files, cache files, and distros put those directories where they live in the on-disk filesystem, even though they are small, and ephemeral, there is no point in keeping them after a reboot, and logs should be sent to another host, not stored on the local machine.

      I've basically solved all these problems, but not the iocache priming problem, as I use a tmpfs root and run my entire OS off ram*. There's not much point sharing my source code for my init generator, as it's too simple and my-use specific to be generally useful, and the idea behind it is what is worth sharing, which I have now done in this posting.

      * there's plenty of other good reasons to do this.

  22. Re:Uh... by normaldotcom · · Score: 4, Informative

    systemd service files are quite straightforward---I'm not sure what kind of monumental effort you are referring to when creating service files. For a simple service, starting/stopping/restarting the service is handled automatically, leaving a very minimal service file.

    For example:

    [Unit]
    Description=AutonNav

    [Service]
    ExecStart=/usr/sbin/autonnav
    Type=forking

    [Install]
    WantedBy=multi-user.target

  23. 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.)