To: debian-devel@lists.debian.org
Subject: A few observations about systemd
From: Juliusz Chroboczek <jch@pps.jussieu.fr>
Date: Sun, 17 Jul 2011 13:54:14 +0200
Message-id: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
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
To: debian-devel@lists.debian.org
Subject: Re: A few observations about systemd
From: Tollef Fog Heen <tfheen@err.no>
Date: Sun, 17 Jul 2011 15:25:23 +0200
Message-id: <87ei1p3upo.fsf@qurzaw.varnish-software.com>
Mail-followup-to: debian-devel@lists.debian.org
In-reply-to: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
]] 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: debian-devel@lists.debian.org
Subject: Re: A few observations about systemd
From: Juliusz Chroboczek <jch@pps.jussieu.fr>
Date: Sun, 17 Jul 2011 15:52:36 +0200
Message-id: <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
In-reply-to: <87ei1p3upo.fsf@qurzaw.varnish-software.com>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
<87ei1p3upo.fsf@qurzaw.varnish-software.com>
> (I'm the systemd maintainer in Debian)
(Shakes hands.)
> | Another case that I've actually been bitten by is that systemd
> | hard-wires runlevel 5 in its SV init compatibility code;
> It does?
I stand corrected, it's actually part of the configuration (symlink from
runlevel5.target to multi-user.target). Tollef, should the Debian
package change that?
> | 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.
From cgroup.c, line 270:
if (path_is_mount_point("/sys/fs/cgroup/systemd") <= 0) {
log_warning("No control group support available, not creating root group.");
return 0;
}
Note that this returns 0, which stands for success.
-- Juliusz
To: Juliusz Chroboczek <jch@pps.jussieu.fr>
Cc: debian-devel@lists.debian.org
Subject: Re: A few observations about systemd
From: Tollef Fog Heen <tfheen@err.no>
Date: Sun, 17 Jul 2011 17:53:56 +0200
Message-id: <87aacc52ej.fsf@qurzaw.varnish-software.com>
Mail-followup-to: debian-devel@lists.debian.org
In-reply-to: <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
<87ei1p3upo.fsf@qurzaw.varnish-software.com> <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
]] Juliusz Chroboczek
Hi,
| I stand corrected, it's actually part of the configuration (symlink from
| runlevel5.target to multi-user.target). Tollef, should the Debian
| package change that?
: tfheen@qurzaw /lib/systemd/system > ls -l runlevel?.target
lrwxrwxrwx 1 root root 15 2011-07-07 13:37 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 2011-07-07 13:37 runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 17 2011-07-07 13:37 runlevel5.target -> multi-user.target
lrwxrwxrwx 1 root root 13 2011-07-07 13:37 runlevel6.target -> reboot.target
: tfheen@qurzaw /lib/systemd/system >
This looks quite correct to me? (It's also what's shipped in the package.)
| > TTBOMK, cgroups are not optional.
|
| From cgroup.c, line 270:
|
| if (path_is_mount_point("/sys/fs/cgroup/systemd") <= 0) {
| log_warning("No control group support available, not creating root group.");
| return 0;
| }
hmm, ok. I suspect it will work much less well without cgroup support
even so, and in general upstream's not interested in supporting
non-linux even if you could make it limp along.
Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
To: debian-devel@lists.debian.org
Cc: Juliusz Chroboczek <jch@pps.jussieu.fr>
Subject: Re: A few observations about systemd
From: Matt Brown <matt@mattb.net.nz>
Date: Sun, 17 Jul 2011 17:07:32 +0100
Message-id: <CAMgEDbQU4h=opuiQR4mck-JyxYhD6-P1f9roYBq9o1mfUFv0ew@mail.gmail.com>
In-reply-to: <87aacc52ej.fsf@qurzaw.varnish-software.com>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
<87ei1p3upo.fsf@qurzaw.varnish-software.com> <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
<87aacc52ej.fsf@qurzaw.varnish-software.com>
On Sun, Jul 17, 2011 at 4:53 PM, Tollef Fog Heen < tfheen@err.no> wrote:
>> | > TTBOMK, cgroups are not optional.
> |
> | From cgroup.c, line 270:
> |
> | if (path_is_mount_point("/sys/fs/cgroup/systemd") <= 0) {
> | log_warning("No control group support available, not creating root group.");
> | return 0;
> | }
>
> hmm, ok. I suspect it will work much less well without cgroup support
> even so, and in general upstream's not interested in supporting
> non-linux even if you could make it limp along.
Indeed, more context is given in the bug mentioned just above that
stanza: https://bugzilla.redhat.com/show_bug.cgi?id=628004, in
particular Lennart's comment:
https://bugzilla.redhat.com/show_bug.cgi?id=628004#c27
"However, it will print a big big warning if you do this, and
will sleep for 5s so that people see it. And I will ignore all bugs reported
when things don't work properly if this is used"
The README also doesn't list cgroups as optional:
REQUIREMENTS:
Linux kernel >= 2.6.30 (with devtmpfs, cgroups; optional but
strongly recommended: autofs4, ipv6)
So cgroups is "optional", but not really if you want a supported
systemd installation :)
--
Matt Brown
matt@mattb.net.nz
Mob +353 86 608 7117 www.mattb.net.nz
To: Matt Brown <matt@mattb.net.nz>
Cc: debian-devel@lists.debian.org
Subject: Re: A few observations about systemd
From: Juliusz Chroboczek < jch@pps.jussieu.fr>
Date: Sun, 17 Jul 2011 18:26:34 +0200
Message-id: <8739i4dgat.fsf@trurl.pps.jussieu.fr>
In-reply-to: <CAMgEDbQU4h=opuiQR4mck-JyxYhD6-P1f9roYBq9o1mfUFv0ew@mail.gmail.com>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
<87ei1p3upo.fsf@qurzaw.varnish-software.com> <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
<87aacc52ej.fsf@qurzaw.varnish-software.com>
<CAMgEDbQU4h=opuiQR4mck-JyxYhD6-P1f9roYBq9o1mfUFv0ew@mail.gmail.com>
> So cgroups is "optional", but not really if you want a supported
> systemd installation :)
Yes, and that's exactly what I find worrying about Lennart's attitude:
he presumes to impose his policy on you -- you must use Linux, you must
use a recent kernel with cgroups enabled, you're not supposed to use
shell scripts, etc.
I really like systemd, but not to the extent of giving up the ability to
pick my own policy.
-- Juliusz
To: debian-devel@lists.debian.org
Subject: [Lennart Poettering] Re: A few observations about systemd
From: Juliusz Chroboczek <jch@pps.jussieu.fr>
Date: Sun, 17 Jul 2011 18:51:17 +0200
Message-id: <87y5zwc0l6.fsf@trurl.pps.jussieu.fr>
In-reply-to: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
Forwarded by permission from the author.
-- Juliusz
--- Begin Message ---
To: Juliusz Chroboczek <jch@pps.jussieu.fr>
Subject: Re: [Juliusz Chroboczek] A few observations about systemd
From: Lennart Poettering < lennart@poettering.net>
Date: Sun, 17 Jul 2011 17:53:38 +0200
Message-id: <20110717155338.GA6393@tango.0pointer.de>
In-reply-to: <7ivcv1cbv5.fsf@lanthane.pps.jussieu.fr>
References: <7ivcv1cbv5.fsf@lanthane.pps.jussieu.fr>
On Sun, 17.07.11 14:47, Juliusz Chroboczek (jch@pps.jussieu.fr) wrote:
> Dear all,
Wow, you are amazingly badly informed.
> 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.
Seriously?
You have a pretty bogus definition of bloat.
If you want to compare systemd in lines-of-code with sysvinit, then you
need to sum everything up: inetd, the numerous rcS scripts and
even the enourmous duplication that sysv init scripts are. And yes,
systemd will easily win if you do: it will be much shorter.
In fact, a minimal systemd system will win in almost very aspect against
a remotely similarly powerful sysvinit system: you will need much fewer
processes to boot. That means much shorter boot times. That means much
fewer resources. You need a smaller set of packages to built it. It's
fewer lines of code. And yet, it will be much more powerful.
Also, systemd does not "take over the role" of modprobe in any way. I
am not sure where you have that from.
> 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.
Oh, come on.
systemd does not depend on Plymouth, it merely interacts with it if it
is around it. Where interaction simply means writing a single message
every now and then to ply to keep it updated how far the boot
proceeded. It's more or a less a single line of text we send over every
now and then in very terse code.
It would be rother strange if we'd spawn a process for this each time
(which would practically double the number of processes we need to spawn
at boot). And even more stupid to spawn a shell script for it (which
would at least triple it).
I am not sure what makes you think D-Bus was only for the "desktop". It
hasn't been for quite some time, as most commercial distros already
shipped Upstart before systemd, which had a hard dependency on it. I
like to think that that "D-Bus" actually stands for "D-Bus Bus", a truly
recursive acronym.
Also, the claim of D-Bus not being useful and unncessary on anything but
the desktop is pure ignorance. Advanced programs need a form of
call-based IPC. Now you have two options: every project can implement
its own IPC, duplicate code, and fuck it up. Or all projects use the
same, powerful one with bindings for all programming languages, that has
been reviewed thoroughly, is well known and hence relatively
secure. Reusing the same code also makes things much smaller, in
contrast to the "bloat" that occurs when everybody implements their own
IPC.
You know, you are welcome to criticise D-Bus for its code or other
qualities. But if you doubt its usefulness or the need for it, then this
reveals more about your nescience than about D-Bus.
> 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.
Oh god. It's about 30 lines of code, which become NOPs if Plymouth is
not around. it's the simplest scheme thinkable, and debloats the system a
lot (see above).
I see no point in supporting numerous alternative implementations of
splash screens. We gently try to push people to use Plymouth, and only
Plymouth, since it is the sanest implementation around. But that
deosn't mean you have to use it. There is no dependency between the
two. It's just that when you use the combination of systemd and Plymouth
you get the most powerful combination. If you use only one of them
things will still work.
If you find short and minimal code "shocking", then you are easily
shocked.
I might recommend you a less drastic language though.
> 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.)
Simply not true. You can assign legacy runlevels to systemd targets
relatively freely, by placing symlinks in /etc/systemd/. (With the
exception of runlevels 0,1,6 which however cannot really be
reconfigured on sysvinit either). I'll not comment on the benefit of
doing so though.
> 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.
That "language" are .ini-files. Everybody knows .ini files. They are so
simple and have been around for so long, that you don't need to learn
them. Many programming languages come with parsers for them out of the
box.
OTOH shell is a turing complete language, and a very weird one on top.
> 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.)
Yeah, well, systemd is a lot more powerful with a much simpler
language. To configure stuff like the IO or CPU scheduler, the CPU
affinity, OOM adjustment, timer slack, capabilities, privilege dropping,
namespaces, control groups, secure bits, and so on, you just need a line
each in the systemd unit files. In shell however, you will have a hard
time. You can install additional packages to make some of these things
work, but that again increases bloat, and slows down boot (since it
multiplies the number of processes you need).
systemd, with all the power it gives you in unit files, encourages
developers to ship their software robust and secure *by default*. In
shell this is not realistically doable, unless you want to pull in a lot
of additional dependencies. Again, systemd helps "debloating", and
sysvinit encourages it.
On top of that, everybody can easily understand systemd unit files,
without having to learn a programming language. Unit files can easily be
generated programmatically and parsed programmatically too. Shell
scripts cannot be, unless you reimplement a full bourne shell
interpereter.
Finally, systemd does not stop you from using shell scripts. There are
certainly things systemd won't do for you, and never will. If that's the
case and you don't want to add that feature to your daemon code itself,
then you are welcome to just spawn a shell script from the unit file,
nothing will stop you.
As every good software should: systemd makes the frequent things easy
and the other thinks possible.
> 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.
Yeah, that is really bogus.
Here's a short and very incomprehensive list of Linux interfaces that
systemd uses that the other Unixes don't have. We make use of these
features and we empower the user and admin to take advantage of them,
which we couldn't if we cared about POSIX and POSIX only:
cgroups
namespaces
selinux
autofs4
capabilities
udev
oom score adjust
RLIMIT_RTTIME
RLIMIT_RTPRIO
ionice
SCHED_RESET_ON_FORK
/proc/$PID/stat
fanotify
inotify
TIOCVHANGUP
IP_TRANSPORT
audit
F_SETPIPE_SZ
CLONE_xxx
BTRFS_IOC_DEFRAG
PR_SET_NAME
PR_CAPBSET_DROP
PR_SET_PDEATHSIG
PR_GET_SECUREBITS
/proc/$PID/comm
/proc/$PID/cmdline
/proc/cmdline
numerous GNU APIs like asprintf
SOCK_CLOEXEC, O_CLOEXEC
/proc/$PID/fd
/dev/tty0
TIOCLINUX
VT_ACTIVATE
TIOCNXCL
KDSKBMODE
/dev/random
/dev/char/
openat() and friends
/proc/$PID/root
waitid()
/dev/disk/by-label/
/dev/disk/by-uuid/
/sys/class/tty/console/active
/sys/class/dmi/id
/proc/$PID/cgroup
\033[3J
/dev/rtc
settimeofday() and its semantics
(sure, some of the other unixes have a few of these features, but that's
not the point, and it doesn't make this POSIX)
And this list isn't complete. It's just grepping through two source
files.
There's a reason why systemd is more powerful than other init systems:
we don't limit ourselves to POSIX, we actually want to give the
user/administrator the power that Linux can offer you.
> 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.
While I haven't had the pleasure to meet Juliusz in private, I find his
personal and public persona annoying online. He writes personal emails
to people telling them how he finds them annoying. He sends FUD mails
around while being amazingly badly informed.
> 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].
Juliusz practices misleading anti-advertising [1], likes to ignore the
fact that all major distros either made systemd the default or include
it in their distro with the exception of Ubuntu.
[1] The mail this mail is a response to.
You know, you personally attack me and that's quite an unfriendly
move. Even if you think I am dick, I can tell you that I am not the one
who runs personal attacks like this, and publicly calls people by their
name.
You write personal hate mail. I don't. Who's the real dick here?
> Conclusion
> ==========
>
> Systemd is the first init replacement worth criticising.
Nah, the conclusion is more likely that nescience doesn't stop people
from writing stupid opinion pieces.
Feel free to forward this to your mailing list, since you wouldn't have
forwarded this to me if you didn't want me to reply to this. And don't
conveniently leave parts out of it.
Cheers,
Lennart
--- End Message ---
To: debian-devel@lists.debian.org
Subject: Re: A few observations about systemd
From: Jon Dowland <jmtd@debian.org>
Date: Mon, 18 Jul 2011 10:30:15 +0100
Message-id: < 20110718093007.GB22304@pris>
Mail-followup-to: debian-devel@lists.debian.org
In-reply-to: <8739i4dgat.fsf@trurl.pps.jussieu.fr>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
<87ei1p3upo.fsf@qurzaw.varnish-software.com> <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
<87aacc52ej.fsf@qurzaw.varnish-software.com>
<CAMgEDbQU4h=opuiQR4mck-JyxYhD6-P1f9roYBq9o1mfUFv0ew@mail.gmail.com>
<8739i4dgat.fsf@trurl.pps.jussieu.fr>
On Sun, Jul 17, 2011 at 06:26:34PM +0200, Juliusz Chroboczek wrote:
> Yes, and that's exactly what I find worrying about Lennart's attitude:
> he presumes to impose his policy on you -- you must use Linux, you must
> use a recent kernel with cgroups enabled, you're not supposed to use
> shell scripts, etc.
Whilst I share your concerns about Poettering's attitude (and my heart sank
only three lines into his reply that you forwarded to -devel), I think only
supporting Linux is entirely his perogative: It's his project, his time and he
can support what he wants. (Or it's Red Hat's time, and they can support
whatever they want). Likewise, a recent kernel does not seem like a problem,
and cgroups seems like a fairly core part of what systemd does.
The shell script thing I have more of a problem with, although I take his point
about the quality of init scripts at present[1].
I don't suppose it would be worth maintaining a patch-set in Debian to support
other OSs: In a hypothetical future where systemd was the default init system
for Debian, it's probably less work to support multiple init systems and let
K*BSD/Hurd/*[2] pick another.
[1] whilst implementing puppet, I filed #629654 and #629910, and I was just
getting started ☹
[2] has anyone started a Debian/Plan 9 yet? ;)
--
Jon Dowland
To: debian-devel@lists.debian.org
Subject: Re: A few observations about systemd
From: Juliusz Chroboczek <jch@pps.jussieu.fr>
Date: Mon, 18 Jul 2011 13:15:49 +0200
Message-id: <87mxgbc00q.fsf@trurl.pps.jussieu.fr>
In-reply-to: <20110718093007.GB22304@pris>
References: <87mxgdcec9.fsf@trurl.pps.jussieu.fr>
<87ei1p3upo.fsf@qurzaw.varnish-software.com> <87ipr1c8uz.fsf@trurl.pps.jussieu.fr>
<87aacc52ej.fsf@qurzaw.varnish-software.com>
<CAMgEDbQU4h=opuiQR4mck-JyxYhD6-P1f9roYBq9o1mfUFv0ew@mail.gmail.com>
<8739i4dgat.fsf@trurl.pps.jussieu.fr> <20110718093007.GB22304@pris>
> I think only supporting Linux is entirely his perogative: It's his
> project, his time and he can support what he wants.
Hmm. I may be wrong, but I was under the impression that he's pushing
systemd as the standard init, not just as his hobby project. Josselin
may have more information.
-- Juliusz