
Systemd programming, 30 months later - mynameislegion
https://lwn.net/Articles/701549/
======
new299
I've basically decided systemd isn't for me and have uninstalled it from my
systems. The last straw for me was a recent security issue:

[https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...](https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet)

Which made me re-evaluate systemd. Fundamentally creating a monolithic tool to
take over from many small single purpose tools seems counter to the UNIX
philosophy, and makes it harder to hack on my (mostly desktop/laptop) systems.

~~~
ergo14
So, what do you use instead?

~~~
antocv
I use OpenRC on my servers, systemd on my desktop/productive-mode laptop.

On some servers I use s6 toolset. Those are nice. OpenRC is nice. It gets the
work done, its so small, its easy to do things with it, and it has less
problems than systemd - which I experience on the desktop. Example, started
using networkd for managing networks, because hey why not, and NetworkManager
is shit, I had gotten tired of typing wpa-supplicant and dhcpcd commands
manually. But then, systemd apparantly takes control over the networking
subsystem not only the network interfaces - it changes sysctl flags and doesnt
delete after itself when asked to stop - it leaves any addresses and other
configuration changes it had done. What!?

edit: As all things, systemd-networkd has its place, its just not on a
developers laptop, maybe it would be great to have in some kind of cloud
environment where you have to configure hordes of machines and virtual
machines in them, with networking and networking subsystem configured
correctly. Then its nice to have a "do-it-all" tool, but then you should also
probably swallow the rest of RedHats output, such as Ansible and look at
Project Atomic.

~~~
ausjke
Alpine Linux uses OpenRC too, the linux preference for Docker these days.

------
baldfat
A article about programming to systemd and how it helped the various
distributions turned into HN emotional responses to bash systemd.

I like systemd and it has helped Linux advance. init was a mess and no one
still has come with a golden response that shows the world how anything would
be better then systemd.

systemd answered a difficult question and hopefully we willsee more similar
advancements shortly for Linux.

~~~
mikekchar
Personally, I would have been ecstatic to see systemd if it hadn't have been
tied directly to GNOME and thereby installed by every distribution that wanted
to include GNOME. My main gripe with systemd is that every other system the
main author of systemd has written has made my computer inoperable time and
time again. I would have liked to have a choice of using systemd or waiting
until I saw it become mature enough that I trusted it.

I just didn't want to be forced to use it in case history repeated itself.
Opting out of systemd is ridiculously difficult due to that GNOME tie-in. It's
one of the most important parts of my system.

I still would prefer not to have systemd, but I will admit that it works
reasonably well for my purposes. I'm pretty upset about how it all went down,
but that's life in the fast lane I guess. Where are the days when everybody
ignored Linux? I should move to BSD ;-)

~~~
vetinari
The Gnome developers were asking for _years_ for someone to step in and
maintain ConsoleKit. Nobody did and there wasn't any hope somebody would.

So they took plan B and used logind, which is part of systemd. People are
still free to develop shims that would work with other init systems - but so
far nobody is willing to do that.

~~~
wott
And the one supposed to maintain ConsoleKit, who abandoned it, was... a
certain Lennart Poettering.

~~~
mattnewton
Yes, it was all part of his evil plan to.. write what he thought a better
overall system would be, and give it to the community for free?

------
bkor
Another nice video discussing the current limitations of using systemd user
sessions for starting up desktop environments (=user session) is:
[https://www.youtube.com/watch?v=hq18daxTkLA](https://www.youtube.com/watch?v=hq18daxTkLA)

On July Martin Pitt already started to discuss some of the difficulties on
systemd-devel mailing list: [https://lists.freedesktop.org/archives/systemd-
devel/2016-Ju...](https://lists.freedesktop.org/archives/systemd-
devel/2016-July/037017.html)

During the systemd conference they've been working to create a good solution
for this.

~~~
digi_owl
So effectively a doubling down on the cockup that is systemd login sessions...

[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=825394](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=825394)

Gotta go faster faster faster...

~~~
bkor
They're making it work in practice. That's quite different from "doubling down
on a cockup". There's various bits which do not work in the current design, so
they have to change things until it does. This effort is being driven not by a
systemd developer, but someone working for Canonical.

These user sessions have existed for various years. Now they're ensuring it'll
work for graphical sessions. How is this fast?

~~~
tremon
Not really. "Making it work in practice" is a perfect recipe for creating a
cockup. It is a perfect illustration of how software engineering isn't.

Do you really want a real, professional engineer to use the strategy "I don't
need verified designs, I'll just make it work in practice" when building a
bridge or railway?

------
__david__
Oh wow, I didn't know about `systemctl mask`. I've been fighting with a
computer that takes forever to boot because of nfs, even though I do not want
nfs enabled. I was trying to use `systemctl disable` to no avail, but `mask`
looks like it'll actually do the trick.

~~~
gosub
Could you elaborate on why `systemctl disable` was not working? I do not
uderstand the difference between mask and disable.

~~~
vetinari
'disable' can still start the service, if another service claims it as a
dependency. It will not start the service, if it is the last one in the
dependency chain.

'mask' will not start the service, not even as a dependency to another
service; instead it will rather let the dependent service fail to start.

~~~
brazzledazzle
That would surprise me at some point. Kind of counter intuitive. Good to know,
thanks for the info.

~~~
lallysingh
Difficulty of naming in software. If they'd named it "block" instead of
"mask", perhaps it'd be clearer?

~~~
tremon
In everyday usage, "disabled" is stronger than "masked". It is indeed
surprising that masking is a stronger operation than disabling. It would be
clearer if the systemd operation names were reversed.

------
throw2016
I think systemd the init should be separated from the rest of it. This will
allow it be more easily managed, secured, developed and be replaceable by
other inits thus retaining one of the most important aspects of Linux and
prevent any single entity beyond the kernel from gaining too much influence.

The functionality that creates these deeper tie ins to Gnome, udev and others
today prevent other inits from working for instance with Gnome. Now they want
to add a kernel bus. This will make it extremely difficult to replace systemd.
Can any supporter of open source and Linux really support this?

A init is a critical subsystem and should have limited scope that is clearly
defined, be thorougly tested for that scope and released. Continuously
developing and adding features to it does not make for a stable experience.
Debian Jessie is now on a outdated version of systemd 2.15 while Systemd is at
2.31.

Things like predictable network names are ironically named as now they are not
predictable to end users and scripts that work across systems. Things like
eth0, eth1, wlan0 abstract the underlying hardware. If your solution cannot
even abstract it and retains the arcane bus names and makes it difficult to
even read let alone work with the interface name how is it a solution.

Things like binary logging may be important to a small subset of users and
they should have an option to enable it. But why should it be imposed on
everyone by default? The technical debt of niche cases should go to those who
want it.

~~~
digi_owl
If you want just the init and accompanying ini-files, perhaps give Nosh a
look?

[https://lists.freedesktop.org/archives/systemd-
devel/2016-Ju...](https://lists.freedesktop.org/archives/systemd-
devel/2016-July/037017.html)

------
mhd
I increasingly get the feeling that systemd is the maven of Linux
administration.

~~~
nurettin
Could you give examples of some of the difficulties people experience using
maven to someone who is not a Java veteran?

~~~
ddalex
Basically, when something goes wrong, it offers no help in what went wrong.
It's a nice idea with a terrible implementation.

~~~
pawadu
Also, a lot of things that were trivial before will now have a long series of
dependencies.

~~~
reitanqild
Heh. To each their own.

I prefer having my dependencies listed in version control, automatically
downloaded, having a tool that can tell me why dependency x is pulled in etc
etc.

~~~
pawadu
Sure, this is all fine when things work correctly. So far, I actually agree
with you.

But once in a while something in the long chain of dependencies fails and
after days of debugging you start thinking you should just have downloaded the
*.jar files and copied them to libs/ manually.

I think people (in general and not only limited to software development)
should strive to minimize dependencies. Otherwise things like this can happen:
[https://news.ycombinator.com/item?id=11340510](https://news.ycombinator.com/item?id=11340510)

~~~
reitanqild
> But once in a while something in the long chain of dependencies fails and
> after days of debugging you start thinking you should just have downloaded
> the *.jar files and copied them to libs/ manually.

Can't you just check the difference between the last working and the first
broken one? If necessary just unpack the last working jar/zip/war side-by-side
the first broken and diff them.

> I think people (in general and not only limited to software development)
> should strive to minimize dependencies.

Here we totally agree. When I started at my current place we had a mix of
spring, javaee, hibernate and whatnot. The size is currently down by almost
70% although a lot of that was also unused resources.

My goal is just using javaee + a couple of utilities.

------
ausjke
On Desktop and servers I had to reluctantly use systemd as-is, no time to
replace it basically. never enjoyed it really.

On embedded linux I make, I use everything else but systemd.

I still worry that over time systemd will be integrated so deeply into linux
that it will be impossible to remove and also leave no chances for
alternatives and if its monolithic approach will be wrong then it will be too
late.

Or maybe systemd wants to be everything, to make even linux obsolete

~~~
geggam
I moved all my servers to BSD. Servers do not need udev gnome or many of the
other things systemd has hooked into.

I have an ubuntu laptop which requires a reboot every so often for a reason I
have yet to figure out.

I am not sure about the linux communities direction after the recent drive to
systemd containers and other complex methods of doing things which should be
simple.

~~~
ausjke
After debian switched to systemd I indeed started to check BSDs again for
servers, but have yet to migrate.

~~~
pmlnr
Same here, except I first burned myself with full disk encrypted ZFS, just to
learn I'm doing it the wrong way.

------
xarope
I've not looked closely at systemd yet, but my initial attempts with using
sysctl on a test ubuntu 16.04 server, seems to reflect my experience with
usage of svcadm in solaris/illumos, where the latter requires XML manifest
instead of a "simple" script.

Is this an apt comparison for systemd, or is it way better/worse (I'm not an
expert, so I'll leave the qualitative opinions to others!) than that?

~~~
wvh
Well, in most (older) init systems, boot scripts were shell scripts and you
could do anything if you knew how, including shooting yourself in the foot.
Great flexibility, great responsibility.

In systemd, services are described in a simple file with a few keywords, and
systemd tries to do all the magic itself, in a way replacing the scripting
part and all the possible code paths that could be gotten that way.

So if something in the system's boot or a process' start-up procedure doesn't
work now, it's systemd's fault and not yours or whoever wrote the shell
scripts in other init systems; and if the simple configuration file is not
complex enough to do something you could do easily with a shell script, than
it's also systemd's fault for being too simple.

I'm an old-timer and I like shell scripting, but also think systemd makes
writing service files easier and has benefits such as built-in support for
cgroups, security features (user/group, chroot, ...) and mini-services like
basic ntp server. There were some bugs when distributions started to include
it by default some years back, but I haven't had any problems lately.

~~~
makomk
One of the problems with systemd seems to be that it makes init scripts _look_
simpler by spreading their complexity across multiple files all over the
filesystem instead. The unit file systemd proponents were showing off as an
example a few years back certainly looked simple compared to the init script
it replaced... until you realise that its functionality had actually been
split across several unit files and a bunch of shell scripts that they called.
Look at this article and just count number of moving parts involved in getting
NFS working with systemd too. Multiple service, target and socket unit files
with the same name but subtly different behaviour, multi-hundred-line shell
scripts in a directory most people won't even realise exists modifying some of
them at runtime, ... In non-systemd init systems that'd all probably be one
init script, and the fact that it was all in one place would sure make it look
more complex.

------
mattbillenstein
I just write one systemd script to start supervisord and ignore the rest of it
basically...

------
reacweb
Very interesting for developpers, but I am still searching for a documentation
about systemd and nfs for non expert users.

~~~
proaralyst
The Arch Linux wiki has good documentation on Systemd:
[https://wiki.archlinux.org/index.php/Systemd](https://wiki.archlinux.org/index.php/Systemd)

~~~
macawfish
I just switched to Arch recently, and only then became aware of systemd. I
have to say (as an init scripting noob) that I appreciate how systemd scripts
seem more naturally organised than init.d scripts.

Having dependencies specified explicitly helps me to understand how the system
works much more easily than cryptic directories full of numbered init scripts
ever have.

~~~
a3n
Same as you, recent Arch switcher. I've never been a professional sysadmin,
just my home network. I've been enjoying systemd from a noob/amateur
perspective.

