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:
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.
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
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
It also has the goal of creating
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
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.
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:
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).
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
The info 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:
Starting job foo:
Stopping job foo:
Restarting job foo:
Checking configuration of job foo:
Listing job's environement variables:
Setting job's environment variable:
Removing job's environment variable:
In upstart logs are normal text files in the /var/log/upstart directory, so you can process them as usual:
In systemd logs are stored in an internal binary format (not as text files) so you need to use
Example upstart script written in
Example systemd script written in
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:
Usage in distributions
Now some recent data according to Wikipedia:
Distributions using upstart by default:
Distributions using systemd by default:
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:
Some websites dedicated to the systemd controversy has been created:
There is a lot of interesting discussion on Hacker News:
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.
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." Here I am comparing the common features of upstart and systemd when used as init systems as asked in the question so I am specifically not talking about use cases that are beyond the scope of an init system. The relevant documentation should be checked for more info.
More info can be found at:
The architecture of systemd on Wikipedia:
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.