Forgot your password?
typodupeerror
Ubuntu Debian Linux

Ubuntu To Switch To systemd 279

Posted by Soulskill
from the follow-the-leader dept.
GuerillaRadio writes "Following the decision for Debian to switch to the systemd init system, Ubuntu founder and SABDFL Mark Shuttleworth has posted a blog entry indicating that Ubuntu will now follow in this decision. 'Nevertheless, the decision is for systemd, and given that Ubuntu is quite centrally a member of the Debian family, that's a decision we support. I will ask members of the Ubuntu community to help to implement this decision efficiently, bringing systemd into both Debian and Ubuntu safely and expeditiously.'"
This discussion has been archived. No new comments can be posted.

Ubuntu To Switch To systemd

Comments Filter:
  • Re:Good...? (Score:4, Informative)

    by s.petry (762400) on Friday February 14, 2014 @01:17PM (#46247387)

    I am with you, I never saw a reason to get rid of SYSV. The reason Linux started pushing is based on the same Logic Sun had to go away from it. A master daemon which monitors all services and their current states, restart when necessary, etc... The Sun implementation took a bit of getting used to, but in reality the daemon used XML files which contained mostly SH scripts. It was still hackable, which is why SYSV stuck around for so long. When something does not work, write a new SH script and stick it in init.

    The Linux implementation is not as straight forward as Sun's implementation which to me says a lot. RH6 went to systemd and I hated it. Cryptic, not hackable, and simply a pain in the ass to customize unless you run everything in legacy mode which is still SYSV. The alleged better logging did not exist, and was much harder to access than "set -x" in an init script.

    The overlord daemon is an advantage, previously we all used monitoring scripts to do things for us. The system now has it built in. I never saw an issue with writing restart options into BigBrother, Nagios, etc.. so don't save much with this small feature. In the grand scheme of things, I lose a lot of flexibility with this system. So most of my custom tools, code, and scripts will run in legacy mode.

  • by Anonymous Coward on Friday February 14, 2014 @01:23PM (#46247453)

    put this line in your .bashrc file

    alias service='systemctl'

  • by joejor (578266) on Friday February 14, 2014 @01:26PM (#46247497)
    Here's a pretty good treatise on the shortcomings of systemd: http://ewontfix.com/14/ [ewontfix.com]
  • Re:Good...? (Score:5, Informative)

    by fishybell (516991) <fishybell&hotmail,com> on Friday February 14, 2014 @01:30PM (#46247533) Homepage Journal

    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.

  • by Anonymous Coward on Friday February 14, 2014 @01:34PM (#46247581)

    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.

  • by fishybell (516991) <fishybell&hotmail,com> on Friday February 14, 2014 @01:39PM (#46247653) Homepage Journal

    Yes, you can do parallel startup with System V. You also can make a systemd init process that doesn't do anything in parallel.

    Yes, systemd is smarter with dependencies in the sense that it has dependencies and not a numered list. Yes, you can have a System V script that manages it's own dependencies, but because you can do an infinite number of things with System V scripts many people have tried. I've ran across dozens of System V scripts that are hundreds of lines long even without couting the standard ". /etc/init.d/functions" size, which, on my system, is almost 600 lines long. Systemd simplies this by having a much larger library of functions and uses the presumption that you'll never call a script without using systemd to manage it. No longer does every script have to define a start, stop, restart, condrestart, status function; it's handled by systemd. No longer do you have to do checks for your PID file; it's handled by systemd. No longer do you have to make sure your script will always run after another script even if that script's chkconfig number changed; it's handled by systemd.

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

  • by broken_chaos (1188549) on Friday February 14, 2014 @01:59PM (#46247897)

    If a daemon has problems and needs to restart itself how does it do that?

    ...Monit [mmonit.com]? runit [smarden.org]? 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.

  • by Narcocide (102829) on Friday February 14, 2014 @02:33PM (#46248273) Homepage

    Look, you coward, systemd is written by someone who can't grock grep. I thought Debian could do no wrong too, but apparently no organization is impervious to beligerant ignorance.

    http://ewontfix.com/14/ [ewontfix.com] (posted elsewhere in this discussion by someone else, this is the well-organized counter-argument you claim to be willing to hear. read it then fuck off)

  • Re:Good...? (Score:4, Informative)

    by nabsltd (1313397) on Friday February 14, 2014 @03:20PM (#46248783)

    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.

    If only systemd were really "smart enough", it would be great. Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it.

    All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence. This really isn't any different in SysV, but at least there I could trivially edit the startup script of the dependent service and add some sort of test.

    Because there is no way to test every combination of services, there is no way to reliably create systemd dependency files that will always work. Because of that, we get things like rc.local running before other services have started completely.

  • Re:Good...? (Score:5, Informative)

    by amorsen (7485) <benny+slashdot@amorsen.dk> on Friday February 14, 2014 @03:25PM (#46248835)

    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.

  • by nabsltd (1313397) on Friday February 14, 2014 @03:38PM (#46249009)

    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:Good...? (Score:4, Informative)

    by JesseMcDonald (536341) on Friday February 14, 2014 @05:41PM (#46250403) Homepage

    Unfortunately, if you have a sevice that needs another service 100% functional before it can run, systemd has no way to describe that in the dependency files nor to test it. All systemd uses to define a "running" service is that a process doesn't throw an immediate error upon startup. And, that's all it can ever have, unless the service is specially coded to be systemd-aware or does something like create a file in /var/run after it has fully initialized, and the dependency can be written using file existence.

    That isn't true. Putting aside the systemd-specific sd_notify() API for reporting just how completely the service has been initialized, and the socket activation model which allows other services to connect while startup is still in progress, systemd also supports traditional "forking" daemons which complete their initialization before the main process exits. You can also use the ExecStartPre and ExecStartPost fields to inject arbitrary commands into the startup process separate from the daemon itself.

    The best case short of actual systemd integration is that the service already does the right thing with the fork-and-exit model, so that it's ready to be used before any other services are started which depend on it. But even if that isn't the case there are ways to deal with it under systemd, up to and including custom shell scripts for the really complex cases.

"Right now I feel that I've got my feet on the ground as far as my head is concerned." -- Baseball pitcher Bo Belinsky

Working...