FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-17-2011, 11:54 AM
Juliusz Chroboczek
 
Default A few observations about systemd

Dear all,

Systemd[1] is the currently fashionable next-generation init
replacement, intended to replace both System V init and Ubuntu's
upstart. Since the Debian systemd package is now operational, I've
decided to try running it on my laptop. Here are my observations after
three days with systemd.

Please note that this mail is not intended to push Debian's policy in
one way or another, which would be premature. Note further that any
opinions expressed in this mail are mine, and mine only, and that they
are subject to change in the future as I grow older and more stupid.


The good
========

Systemd works
-------------

It is easy to get systemd to work on a Debian system. Just install the
systemd package, and reboot after adding "init=/bin/systemd" to the
kernel's command line. (I'm running testing, so I've had to pull a few
packages from sid to get systemd to install.)

In addition to the issues described on the wiki[1], I'm sufferring from
a deadlock on shutdown that is resolved by systemd timing out after
a couple of minutes.


Systemd is documented
---------------------

Systemd comes with extensive documentation, in the form of well-written
manual pages; additionally, there is a series of (somewhat verbose) blog
postings by the author that explain the rationale.

(The documentation does need more work, though. For example I couldn't
find the complete set of service states, and it took me some time to
discover how native and SV services interact.)


Systemd makes sense
-------------------

Unlike upstart, which I've never managed to get my head around, systemd
actually makes sense to me. It has a sane notion of dependency,
a relatively sane notion of service, a comprehensible notion of target
(the equivalent of a runlevel). While I may not like systemd's
obsession with socket activation, it too is a notion that makes sense.


Systemd got services right
--------------------------

What systemd definitely got right are services, in more than one way.

### Services are launched by init

With SV init, a deamon is launched by a descendant of whoever started
the initscript. The daemon may inherit file descriptors from somebody's
login shell, which may end up e.g. preventing a filesystem from getting
unmounted. (And no, CLOEXEC is not a solution.)

With systemd, services are launched by the init daemon, which has
hopefully been able to preserve a clean environment. (This is also the
case with all other modern init replacements, notably upstart and
runit.)

### Services have a sane life cycle

Systemd services have a sane life cycle, and are monitored by systemd in
a variety of ways. Thanks to cgroups, systemd is able to reliably kill
or restart a service -- no more rogue processes that are left after
you've stopped a daemon.

(Not everything is perfect, though. Systemd perpetuates SV init's
confusion between daemons -- things that keep running -- and
initialisation scripts -- things that must be run at some point during
the boot process, but don't really have a state.)

### Defining a service is a piece of cake

Writing a native service for systemd is a pleasure -- it's a matter of
writing a simple config file, in a human-readable syntax (no XML),
typically 3 to 6 lines long, and soft-linking it to the right place.
Compare that with SV init, where writing an init script takes the best
part of an hour and involves getting the syntax of start-stop-daemon
wrong at least three times.

Most of the features that you'd expect are present, including setuid,
redirecting output to syslog, resource limits etc. One thing that I've
found missing is the ability to redirect output to a log file in
a manner compatible with logrotate (without going through syslog), but
perhaps I haven't looked hard enough.

The format of a service definition is sane enough to allow for automatic
conversion to a different format; I think it would be quite doable to
automatically convert systemd's definitions to SV init scripts or to the
format of whatever is the next fashionable init replacement after
systemd.

### System V initscripts are monitored

Unlike all other init replacements known to me, systemd is able to
monitor daemons launched from System V init scripts just as reliably as
native services. This is an amazingly cool feature.


The bad
=======

Systemd is bloated
------------------

Systemd is bloated. It apparently attempts to take over the roles of
init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and
probably others. The result is that you end up running 50000 lines of
C code as PID 1, as compared to the 8000 lines of SV init or the 6000
lines of runit.


Systemd is layered strangely
----------------------------

For a low-level piece of infrastructure, systemd interacts with a lot of
high-level software; while this might be okay for a workstation running
Gnome, it makes me wonder whether it will be usable on servers.
A cursory look shows that systemd intrinsically depends on D-Bus (the
*desktop* bus) and knows about Plymouth, RedHat's implementation of
a splash screen. More on that below.


Systemd hard-wires special cases
--------------------------------

Rather than relying on distribution-specific shell scripts, systemd
hard-wires much of its behaviour in C code. The most shocking case,
already mentioned above, is that systemd interacts with Plymouth. This
is not done by using some generic early-boot protocol -- systemd
contains code that is explicitly meant to communicate with Plymouth, the
one and only implementation of a splash screen.

Another case that I've actually been bitten by is that systemd
hard-wires runlevel 5 in its SV init compatibility code; that's merely
inflexible under Fedora, but clearly wrong under Debian. (I've now
fixed my system to run the exact same initscripts in all four multi-user
runlevels.)


Systemd deprecates shell scripts
--------------------------------

With systemd, you're no longer supposed to write your service
definitions in shell; instead, you write them in systemd's declarative
language. Where you used to say

ulimit -d 40000000

you now say

LimitDATA = 40000000

The trouble with that is that while we all know how to write shell
scripts, systemd requires that we learn a new language. What is more,
we are now limited to configuring those aspects that systemd's author
has implemented; this is unlike shell scripts, where we can configure
anything that can be configured either from the shell or from a utility
callable from the shell. (Compare with runit, which simply ships with
a utility to change a bunch of process paramaters not otherwise
tweakable from the shell, and expects you to write a single-line shell
script in order to tweak process state.)


Systemd is Linux-specific
-------------------------

Systemd is specific to Linux. This is strange, since the only feature
of Linux used by systemd that doesn't have an exact equivalent on other
systems, cgroups, is optional in systemd.


Systemd's author is annoying
----------------------------

While I haven't had the pleasure to meet Lennart in private, I find his
public persona annoying, both on-line and at conferences. He practices
misleading advertising[2], likes to claim that the universal adoption of
systemd by all distributions is a done thing[3], and attempts to bully
anyone who has the gall to think that the discussion is still open[4].


Conclusion
==========

Systemd is the first init replacement worth criticising.


[1] http://wiki.debian.org/systemd

[2] See the comparative tables on http://0pointer.de/blog/projects/why.html .
They remind me of the advertising for Microsoft Quick C.

[3] "Since then most of the big distributions have decided to adopt it
in one way or another..." http://0pointer.de/blog/projects/why.html

[4] "Well, I guess we simply have to disagree. My interest is a tighly
integrated, small, minimal, lightweight system. Yours seem to be a big,
archaic, chaotic, redundant, resource intensive system. But that's
fine." http://osdir.com/ml/fedora-devel-list/2011-06/msg01065.html
 
Old 07-17-2011, 01:25 PM
Tollef Fog Heen
 
Default A few observations about systemd

]] Juliusz Chroboczek

(I'm the systemd maintainer in Debian)

| Systemd is bloated
| ------------------
|
| Systemd is bloated. It apparently attempts to take over the roles of
| init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and
| probably others. The result is that you end up running 50000 lines of
| C code as PID 1, as compared to the 8000 lines of SV init or the 6000
| lines of runit.

I disagree with this and you're muddying the waters:

it uses modprobe, it uses mount and setting the host name has always
been part of the boot process, so that init is doing this is just a
change in the sense that it's done by C code rather than a shell script,
so in those cases it just does what is already done by a bunch of shell
scripts.

as for trying to take over inetd's role: yes, it can replace inetd. You
don't have to do that, though. Replace cron and at? Not really, it has
support for timer events, but it does not have any replacement for the
user part of at and cron, so while it can do some of what at and cron
can, it's currently no replacement for them.

| For a low-level piece of infrastructure, systemd interacts with a lot of
| high-level software; while this might be okay for a workstation running
| Gnome, it makes me wonder whether it will be usable on servers.

I don't see why it shouldn't be.

| A cursory look shows that systemd intrinsically depends on D-Bus (the
| *desktop* bus) and knows about Plymouth, RedHat's implementation of
| a splash screen. More on that below.

It uses dbus as an IPC mechanism rather than inventing its own. It does
not depend on dbus-daemon.

| Systemd hard-wires special cases
| --------------------------------
|
| Rather than relying on distribution-specific shell scripts, systemd
| hard-wires much of its behaviour in C code. The most shocking case,
| already mentioned above, is that systemd interacts with Plymouth. This
| is not done by using some generic early-boot protocol -- systemd
| contains code that is explicitly meant to communicate with Plymouth, the
| one and only implementation of a splash screen.

What's so shocking about this? If somebody either creates a common API
that all splash implementations can use (and make plymouth switch to
that), I'm sure systemd will switch too. The point is there is no
current generic early boot protocol.

| Another case that I've actually been bitten by is that systemd
| hard-wires runlevel 5 in its SV init compatibility code; that's merely
| inflexible under Fedora, but clearly wrong under Debian. (I've now
| fixed my system to run the exact same initscripts in all four multi-user
| runlevels.)

It does? To the best of my knowledge the Debian package does not treat
any of the «normal» runlevels differently.

| With systemd, you're no longer supposed to write your service
| definitions in shell; instead, you write them in systemd's declarative
| language. Where you used to say
|
| ulimit -d 40000000
|
| you now say
|
| LimitDATA = 40000000
|
| The trouble with that is that while we all know how to write shell
| scripts, systemd requires that we learn a new language. What is more,
| we are now limited to configuring those aspects that systemd's author
| has implemented; this is unlike shell scripts, where we can configure
| anything that can be configured either from the shell or from a utility
| callable from the shell.

ExecStart=/bin/sh -c 'ulimit -d 4000000; some_daemon'

should work just fine. (Sure, it's a bit ugly, and if you have anything
that makes sense to make generally available, we'll happily add it.)

| Systemd is Linux-specific
| -------------------------
|
| Systemd is specific to Linux. This is strange, since the only feature
| of Linux used by systemd that doesn't have an exact equivalent on other
| systems, cgroups, is optional in systemd.

TTBOMK, cgroups are not optional.

Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ei1p3upo.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87ei1p3upo.fsf@qurzaw.varnish-software.com
 

Thread Tools




All times are GMT. The time now is 02:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org