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?
Init Systems – Pros and Cons of Upstart and systemd
initsystemdupstart
Related Solutions
For the second question, the answer is no and you should have a look at Resources for portable shell programming.
As for the first part - first of all, you certainly have to be careful. I'd say perform several tests to make sure - because the fact that someone does have systemd (for ex.) installed, does not mean it is actually used as the default init
. Also, looking at /proc/1/comm
can be misleading, because some installations of various init programs can automatically make /sbin/init
a symlink hardlink or even a renamed version of their main program.
Maybe the most useful thing could be to look at the init scripts type - because those are what you'll actually be creating, no matter what runs them.
As a side note, you might also have a look at OpenRC which aims to provide a structure of init scripts that is compatible with both Linux and BSD systems.
Probably everything you want to know is here on the "Debate Init System To Use" pages that the Debian project put together around making the decision of which initsystem to go with. Within that page is a separate link to each of the choices of initsystems.
For a primer on Systemd this page has pretty much everything one would need to know to get started with it, RHEL7: How to get started with Systemd.
Additional resources that I found helpful in getting a better understanding of the 2 primary choices I'd also read the Wikipedia pages on the respective technologies:
The Gentoo project also maintains a nice comparison of some of the key features across the various initsytems:
My take on your questions
Q#1: How does systemd compare to other init systems?
This is a very tough question to address in the space of an SE answer so I'd rather defer to the various sources that I've referenced above. I'll say this though. In reading through much of the articles about systemd
of the alternatives it's trying to address many aspects of what were deficient in previous tools used for starting up services on Linux systems. It has a very well thought out design and is attempting to provide it in a very modular way.
So IMO, I would say that it compares very favorably both in terms of the effort in its design, execution of that design, and the adoption of it by several larger Linux distros.
Q#2: What sets it apart -- what can it do that the other init systems cannot?
The are many things that sytemd
can do that other systems cannot. Probably 3 of its strongest features are:
- Logging
- Resource Limiting
- Dealing with daemons that fork
1. logging
On the logging front, systemd
has instituted a new logging system called the "Journal", the service is called systemd-journald.service
. This is its own topic, you can read more about it here in this article titled: Introducing the Journal. Here's an example of a user, "harald", logging in.
_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500
2 & 3. Resource limiting & daemons that fork
systemd
uses a novel approach here of using cgroups
to both contain and resource limit any services that require forking or limiting of access to resources.
excerpt
Systemd has a very clever solution to the problem of tracking daemons that fork, which coincidentally happens to handle resource limiting at the same time. Where Upstart uses ptrace to watch the forking, systemd runs each daemon in a control group (requires Linux 2.6.24 or newer) from which it can not escape with any amount of forking. This allows easy resource limiting , both for forking and non-forking daemons, since control groups were made for this sort of thing.
Source:Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
Q#3: Is there anything to lose in switching to it from another init system?
Probably the biggest caveat to switching to systemd over Upstart or sysV init is having to embrace a lot of new complexities. Systemd has a lot of moving parts and is extremely feature rich and with that added capabilities you'll likely be spending a fair amount of time gaining understandings around how it all works.
Q#4: How does administering systemd compare to the others?
As stated in my above answer to Q#3. I'l reiterate here again. Where sysV init was fairly trivial to learn how to manage and navigate in a few hours to days, Upstart will likely take you a week or more to get up to speed, while systemd will likely take you much longer, I'm anticipating taking several weeks to gain enough cursory knowledge about it, where I'll be able to both produce my own .service
files, to stopping/starting services with the same ease that I now enjoy with sysV init.
Best 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 runningsudo 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.)Most of 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, see sections below for detailed explanation. This answer is comparing the old behavior of Upstart-based systems with the new behavior of systemd-based systems, as asked in the question, but note that the commands tagged as "Upstart" are not necessarily Upstart-specific - they are often commands that are common to every non-systemd Linux and Unix system.
Commands
Running su:
su
machinectl shell
(see "su command replacement" section below)
Running screen:
screen
systemd-run --user --scope screen
(see "Unexpected killing of background processes" section below)
Running tmux:
tmux
systemd-run --user --scope tmux
(see "Unexpected killing of background processes" section below)
Starting job foo:
start foo
systemctl start foo
Stopping job foo:
stop foo
systemctl stop foo
Restarting job foo:
restart foo
systemctl restart foo
Listing jobs:
initctl list
systemctl status
Checking configuration of job foo:
init-checkconf /etc/init/foo.conf
systemd-analyze verify /lib/systemd/system/foo.service
Listing job's environement variables:
initctl list-env
systemctl show-environment
Setting job's environment variable:
initctl set-env foo=bar
systemctl set-environment foo=bar
Removing job's environment variable:
initctl unset-env foo
systemctl unset-environment foo
Logs
In upstart, the 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
journalctl
command to access them:Scripts
Example upstart script written in
/etc/init/foo.conf
:Example systemd script written in
/lib/systemd/system/foo.service
:su command replacement
A
su
command replacement was merged into systemd in pull request #1022:because, according to Lennart Poettering, "su is really a broken concept".
He explains that "you can use su and sudo as before, but don't expect that it will work in full".
The official way to achieve a
su
-like behavior is now:It has been further explained by Lennart Poettering in the discussion to issue #825:
See also:
Unexpected killing of background processes
Commands like:
no longer work as expected. For example,
nohup
is a POSIX command to make sure that the process keeps running after you log out from your session. It no longer works on systemd. Also programs likescreen
andtmux
need to be invoked in a special way or otherwise the processes that you run with them will get killed (while not getting those processes killed is usually the main reason of running screen or tmux in the first place).This is not a mistake, it is a deliberate decision, so it is not likely to get fixed in the future. This is what Lennart Poettering has said about this issue:
For more info see:
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:
(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:
The official Debian position on systemd
The systemd controversy
Debian Exodus declaration in 2014:
Some websites and articles dedicated to the systemd controversy has been created:
There is a lot of interesting discussion on Hacker News:
Similar tendencies in other distros can be observed as well:
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:
Areas already covered:
Work in progress:
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.