Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It appears systemd is the hot new init system on the block, same as Upstart was a few years ago. What are the pros/cons for each? Also, how does each compare to other init systems?

share|improve this question
9  
It would also be nice to add openrc, from Gentoo, to the comparison. – Keith Jan 15 '11 at 4:28
4  
@keith iirc openrc simply uses SysV, the advantage is a well designed collection of startup scripts that use common components and are portable (meaning work on any shell) It's a good cleanup, but not really a new initd – xenoterracide Jan 21 '11 at 19:26
    
@xeno It does, but you can't really tell. there are no rcX.d or [KS] symlinks at all. Actually sysv init itself is pretty flexible, and the runlevels are not really used in the usual way. – Keith Jan 22 '11 at 20:15
    
Although the author of this blog is against systemd, I suggest giving this a read. It goes over the pros and cons of systemd and BSD init. textplain.net/blog/2015/… – Peschke Jun 3 at 15:48

Both upstart and systemd are attempts to solve some of the problems with the limitations of the traditional SysV init system. For example, some services need to start after other services (for example, you can't mount NFS filesystems until the network is running), but the only way in SysV to handle that is to set the links in the rc#.d directory such that one is before the other. Add to that, you might need to re-number everything later when dependencies are added or changed. Upstart and Systemd have more intelligent settings for defining requirements. Also, there's the issue with the fact that everything is a shell script of some sort, and not everyone writes the best init scripts. That also impacts the speed of the startup.

Some of the advantages of systemd I can see:

  • Every process started gets its own cgroup or a particular cgroup.
  • Pre-creation of sockets and file handles for services, similar to how xinetd does for it's services, allowing dependent services to start faster. For example, systemd will hold open the filehandle for /dev/log for syslog, and subsequent services that send to /dev/log will have their messages buffered until syslogd is ready to take over.
  • Fewer processes run to actually start a service. This means you aren't writing a shell script to start up your service. This can be a speed improvement, and (IMO) something easier to set up in the first place.

One disadvantage I know of is that to take advantage of systemd's socket/FH preallocation, many daemons will have to be patched to have the FH passed to them by systemd.

share|improve this answer
10  
PulseAudio is a much-maligned sound system (pulseaudio.org), originally written by Lennart Poettering, the author of systemd. I was mostly making a joke here, because I know several people who like to complain about pulseaudio and I'm sure they'd complain about systemd too. Honestly, I haven't had a problem with either systemd or pulseaudio. – jsbillings Jan 20 '11 at 17:48
4  
Makes one almost pine for the abundant fiords of Plan9... everything's a file. – Barry May 11 '11 at 9:29
4  
To be honest, pulseaudio was a solution to a non-existant problem. There's nothing PA can do that ALSA can't, and I've heard PLENTY of people having issues with PA, over and over again. – Hugo Jul 23 '12 at 4:37
3  
Two systemd disadvantages you missed: (1) all startup scripts need to be rewritten. (2) there's way less compatibility with non-linux OSs (like BSDs, for example). – Hugo Jul 23 '12 at 4:38
6  
Just great. Please take a look at 0pointer.de/blog/projects/the-biggest-myths. I witnessed systemd's growth, and can attest that much of the criticisms given here are completely groundless. At the link you will find a blow by blow, reasoned rebuttal. – vonbrand Jan 27 '13 at 22:45

Saw systemd mentioned on Arch General ML today. So read up on it. The H Online as ever is a great source for Linux Technology and is where I found my place to start researching Systemd as SysV Init and Upstart alternative. However the H Online article (in this case) isn't a very useful read, the real use behind it is it gives links to the useful reads.

The real answer is in the announcement of systemd. Which gives some crucial points of what's wrong with SysV initd, and what new systems need to do

  • To start less.
  • And to start more in parallel.

Its major plan to do this seems to be to start services only as they're needed, and to start a socket for that service, so that the service that needs it can connect to the created socket long before the daemon is fully online. Apparently a socket will retain a small amount of buffered data meaning that no data will be lost during the lag, it will be handled as soon as the daemon is online.

Another part of the plan seems to be to not serialize filesystems, but instead mount those on demand as well, that way you're not waiting on your /home/, etc (not to be confused with /etc) to mount, and/or fsck when you could be starting daemons as / and /var/ etc, are already mounted. It said it was going to use autofs to this end.

It also has the goal of creating .desktop style init descriptors as a replacement for scripts. This will prevent tons of slow sh processes and even more forks of processes from things like sed and grep that are often used in shell scripts.

They also plan not to start some services until they are asked for, and perhaps even shut them off if they are no longer needed, bluetooth module, and daemon are only needed when you're using a bluetooth device for example. Another example given is the ssh daemon. This is the kind of thing that inetd is capable of. Personally I'm not sure I like this, as it might mean latency when I do need them, and in the case of ssh I think it means a possible security vulnerability, if my inetd were compromised the whole system would be. However, I've been informed that using this to breach this system is infeasible and that if I want to I can disable this feature per service and in other ways.

Another feature is apparently going to be the capability to start based on time events, either at a regularly scheduled interval or at a certain time. This is similar to what crond and atd do now. Though I was told it will not support user "cron". Personally this sounds like the most pointless thing. I think this was written/thought up by people who don't work in multiuser environments, there isn't much purpose to user cron if you're the only user on the system, other than not running as root. I work on multiuser systems daily, and the rule is always run user scripts as the user. But maybe I don't have the foresight they do, and it will in no way make it so that I can't run crond or atd, so it doesn't hurt anyone but the developers I suppose.

The big disadvantage of systemd is that some daemons will have to be modified in order to take full advantage of it. They'll work now, but they'd work better if they were written specifically for its socket model.

It seems for the most part the systemd's peoples problem with upstart is the event system, and that they believe it to not make sense or be unnecessary. Perhaps their words put it best.

Or to put it simpler: the fact that the user just started D-Bus is in no way an indication that NetworkManager should be started too (but this is what Upstart would do). It's right the other way round: when the user asks for NetworkManager, that is definitely an indication that D-Bus should be started too (which is certainly what most users would expect, right?).
A good init system should start only what is needed, and that on-demand. Either lazily or parallelized and in advance. However it should not start more than necessary, particularly not everything installed that could use that service.

As I've already said this is discussed much more comprehensively in the announcement of systemd.

share|improve this answer
    
sorry but the announcement is like a book. I have to read and grok, before I can really include more here. – xenoterracide Jan 20 '11 at 15:56
2  
How is this better than @John's answer? Is it a placeholder? A promo of H Online? – Tshepang Jan 20 '11 at 17:46
1  
@tshepang well it actually links to the announcement of system d and the h online stuff has links to that and other interesting links. it's a long tedious read. I might add more once I've groked it... this is not a simple subject. when I wrote this I figured you might want to start reading sooner than later. but feel free to mod me down. certainly @jsbillings answer is decent, and better than mine so far. but not as good as reading the announcement itself – xenoterracide Jan 20 '11 at 18:03
    
@tshepang I will probably add more tomorrow, after bed. h online stuff was just me being a good journalist and citing my sources. – xenoterracide Jan 20 '11 at 18:05
    
@tshepang. I've updated my answer. pretty sure I'm done unless the helpful people on irc://frenode.net/systemd decide they want to offer up a correction of some kind. – xenoterracide Jan 21 '11 at 19:20

Well one thing most of you forgot is the organisation of processes in cgroups.

So if systemd started a thing, it will put this thing in its own cgroup and there is no (unpriviledged) mean for the process to escape that cgroup. Here's the consequences of that:

  • An administrator of a big system with many users has efficient new ways to identify malicious users/processes.
  • The priorities for CPU-scheduling can be determined better as done by the "Wonder autocgroup patch".
share|improve this answer

For a very detailed look at systemd, starting with the first design drafts (and a detailed critique of existing init systems, including upstart, and how systemd proposes to fix them), go to its home page. Over time, there have been several articles on startup published in LWN. Just be advised that any mention of systemd (or pulseaudio) there triggers neverending flamewars.

IMVHO (and as a Fedora user) I'm very happy with it. Something in this line was long overdue to handle the complexity of current Linux systems. Fedora used upstart for a while, but it never got out of the stage of being a fancy replacement for sysvinit, running mostly unchanged init scripts. Its promise of simplifying boot configuration comes at the cost of again manually setting up interdependencies, and that just doesn't work. systemd figures dependecies out by itself (or just allows starting stuff without regard of dependencies, they sort themselves out). Another big advantage (some say it is a severe disadvantage) is that it exploits Linux-specific features to the hilt (notably cgroups allow isolating a daemon and all its descendants, so it is easy to monitor, limit the resources, or kill them as a group; there are many others).

share|improve this answer

2016 Update

Most answers here are five years old so it's time for some updates.

Ubuntu used to use upstart by default but they abandoned it last year in favor of systemd - see:

Because of that there is a nice article Systemd for Upstart Users on Ubuntu wiki - very detailed comparison between upstart and systemd and a transition guide from upstart to systemd.

(Note that according to the Ubuntu wiki you can still run upstart on current versions of Ubuntu by default by installing the upstart-sysv and running sudo update-initramfs -u but considering the scope of the systemd project I don't know how it works in practice, or whether or not systemd is possible to uninstall.)

The info in the Commands and Scripts sections below is adapted from some of the examples used in that article (that is conveniently licensed just like Stack Exchange user contributions under the Creative Commons Attribution-ShareAlike 3.0 License).

Here is a quick comparison of common commands and simple scripts:

Commands

Starting job foo:

  • upstart: start foo
  • systemd: systemctl start foo

Stopping job foo:

  • upstart: stop foo
  • systemd: systemctl stop foo

Restarting job foo:

  • upstart: restart foo
  • systemd: systemctl restart foo

Listing jobs:

  • upstart: initctl list
  • systemd: systemctl status

Checking configuration of job foo:

  • upstart: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Listing job's environement variables:

  • upstart: initctl list-env
  • systemd: systemctl show-environment

Setting job's environment variable:

  • upstart: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Removing job's environment variable:

  • upstart: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Logs

In upstart logs are normal text files in the /var/log/upstart directory, so you can process them as usual:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

In systemd logs are stored in an internal binary format (not as text files) so you need to use journalctl command to access them:

sudo journalctl -u foo
sudo journalctl -u foo -f

Scripts

Example upstart script written in /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Example systemd script written in /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

High-level startup concept

In a way systemd works backwards - in upstart jobs start as soon as they can and in systemd jobs start when they have to. At the end of the day the same jobs can be started by both systems and in pretty much the same order, but you think about it looking from an opposite direction so to speak.

Here is how Systemd for Upstart Users explains it:

Upstart's model for starting processes (jobs) is "greedy event-based", i. e. all available jobs whose startup events happen are started as early as possible. During boot, upstart synthesizes some initial events like startup or rcS as the "tree root", the early services start on those, and later services start when the former are running. A new job merely needs to install its configuration file into /etc/init/ to become active.

systemd's model for starting processes (units) is "lazy dependency-based", i. e. a unit will only start if and when some other starting unit depends on it. During boot, systemd starts a "root unit" (default.target, can be overridden in grub), which then transitively expands and starts its dependencies. A new unit needs to add itself as a dependency of a unit of the boot sequence (commonly multi-user.target) in order to become active.

Usage in distributions

Now some recent data according to Wikipedia:

Distributions using upstart by default:

Distributions using systemd by default:

(See Wikipedia for up to date info)

Distributions using neither Upstart nor systemd:

Controversy

In the past A fork of Debian has been proposed to avoid systemd. The Devuan GNU+Linux was created - a fork of Debian without systemd (thanks to fpmurphy1 for pointing it out in the comments).

For more info about this controversy, see:

As many of you might know already, the Init GR Debian vote promoted by Ian Jackson wasn't useful to protect Debian's legacy and its users from the systemd avalanche.

This situation prospects a lock in systemd dependencies which is de-facto threatening freedom of development and has serious consequences for Debian, its upstream and its downstream.

The CTTE managed to swap a dependency and gain us time over a subtle install of systemd over sysvinit, but even this process was exhausting and full of drama. Ultimately, a week ago, Ian Jackson resigned. [...]

I am resigning from the Technical Committee with immediate effect.

While it is important that the views of the 30-40% of the project who agree with me should continue to be represented on the TC, I myself am clearly too controversial a figure at this point to do so. I should step aside to try to reduce the extent to which conversations about the project's governance are personalised. [...]

Devuan was born out of a controversy over the decision to use as the default init system for Debian. The official Debian position on systemd is full of claims that others have debunked. Interested readers can continue discussing this hot topic in The systemd controversy. However we encourage you to keep your head cool and your voice civil. At Devuan we’re more interested in programming them wrong than looking back. [...]

Some websites dedicated to the systemd controversy has been created:

There is a lot of interesting discussion on Hacker News:

Philosophy

upstart follows the Unix philosophy of DOTADIW - "Do One Thing and Do It Well." It is a replacement for the traditional init daemon. It doesn't do anything other than starting and stopping services. Other tasks are delegated to other specialized subsystems.

systemd does much more than that. In addition to starting and stopping services it also manages passwords, logins, terminals, power management, factory resets, log processing, file system mount points, networking and much more - see the NEWS file for some of the features.

Plans of expansion

According to A Perspective for systemd What Has Been Achieved, and What Lies Ahead presentation by Lennart Poettering in 2014 at GNOME.asia, here are the main objectives of systemd, areas that were already covered and those that were still in progress:

systemd objectives:

Our objectives

  • Turning Linux from a bag of bits into a competitive General Purpose Operating System.
  • Building the Internet’s Next Generation OS Unifying pointless differences between distributions
  • Bringing innovation back to the core OS

  • Desktop, Server, Container, Embedded, Mobile, Cloud, Cluster, . . . These areas are closer together than you might think

  • Reducing administrator complexity, reliability without supervision
  • Everything introspectable
  • Auto discovery, plug and play is key
  • We fix things where they are broken, never tape over them

Areas already covered:

What we already cover:

init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, readahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, console managment, . . .

Work in progress:

What we are working on:

  • network management
  • systemd-networkd
  • Local DNS cache, mDNS responder, LLMNR responder, DNSSEC verification
  • IPC in the kernel
  • kdbus, sd-bus
  • Time synchronisation with NTP
  • systemd-timesyncd
  • More integration with containers
  • Sandboxing of Services
  • Sandboxing of Apps
  • OS Image format
  • Container image format
  • App image format
  • GPT with auto-discovery
  • Stateless systems, instantiatable systems, factory reset
  • /usr is the OS
  • /etc is (optional) configuration
  • /var is (optional) state
  • Atomic node initialisation and updates
  • Integration with the cloud
  • Service management across nodes
  • Verifiable OS images
  • All the way to the firmware
  • Boot Loading

Scope of this answer

As fpmurphy1 noted in the comments, "It should be pointed out that systemd has expanded its scope of work over the years far beyond simply that of system startup."

I tried to include most of the relevant info here. Here I am comparing the common features of Upstart and systemd when used as init systems as asked in the question and I only mention features of systemd that go beyond the scope of an init system because those cannot be compared to Startup, but their presence is important to understand the difference between those two projects. The relevant documentation should be checked for more info.

More info

More info can be found at:

Extras

The LinOxide Team has created a Systemd vs SysV Init Linux Cheatsheet.

share|improve this answer
1  
... and such a fork of Debian has occurred. Devuan GNU+Linux is a fork of Debian without systemd. – fpmurphy1 Jun 2 at 22:30
1  
It should be pointed out that systemd has expanded its scope of work over the years far beyond simply that of system startup. – fpmurphy1 Jun 2 at 22:38
    
@fpmurphy1 Thanks for your comments - I updated my answer and added the info that you provided. – rsp Jun 2 at 23:21

Journaling - Systemd is literally like WinSXS folder when it comes to logging stuff, it creates copies of copies unless you manually delete or reduce the file size it will keep eating away at your drive. I call it boot loader cookies.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.