
Systemd Sucks, Long Live Systemd - naftulikay
https://naftuli.wtf/2017/01/12/systemd-is-awful/
======
krylon
At the risk of sounding heretical, I kind of find myself in the middle ground
regarding systemd - I was initially highly skeptical of it, and I still think
it's problematic that it is so Linux-centric and will cause problems
maintaining software to run both on Linux/systemd and on *BSD. The way it was
pushed on distros was problematic, in my opinion.

But having used a couple of Linux systems running systemd - Raspian Jessie and
openSUSE - I have to admit it's not that bad. In practice - on laptops and
desktop systems (assuming one counts the Pi as a desktop system; for my use
case, I do) - I had no problems with it. Enabling and disabling services is a
lot easier. I do not think is as great as its proponents claim, but it's not
as bad as some people think, either. Personally, I have come to appreciate
journald, even though I still agree that binary logs are a bad idea. At least
there is still the option of installing a syslog daemon.

~~~
danieldk
I am also in the middle ground, but I have moved from the opposite direction.
I used to like systemd a lot, especially for its simple unit files (compared
to ugly System V shell scripts) and the fact that it could properly track
processes and restart them on failure.

I have become a bit more skeptical, because most of the problems that I
recently had seemed to be related to systemd. Including some networking
problems, long boot delays because systemd decides to wait 90 seconds be
default on some conditions that it considers to be errors, and problems such
as having to restart systemd-logind manually because of some d-bus update [1].
Before the update, logging in via SSH blocked for a large amount of time.

The most annoying part is that some of the problems take quite a bit of work
to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

[1] [https://major.io/2015/07/27/very-slow-ssh-logins-on-
fedora-2...](https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/)

~~~
pawadu
I think systemd would benefit from a slower adaptation.

The network and boot issues that practically everyone have encountered are
mostly due to incorrect default configurations. This shows that the
maintainers are not ready to use systemd as they don't yet fully understand
it.

~~~
sevensor
Like PulseAudio in its early years, systemd bothers a lot of people because it
was pushed out before it was quite ready, and therefore breaks things that
used to work. But also like PulseAudio, it solves a whole lot of problems for
which the solutions were becoming increasingly hacky and unstable. I don't
believe a slower roll-out would have helped in either case, because many of
the issues were undetectable without a broad user base.

Anti-Lennart partisans would say here that both pieces of software are broken
by design and leave in a huff. I sympathize with their aversion to complexity,
but I'll take a complex init system and simple configuration over a simple
init system with baroque configuration.

~~~
pawadu
From a users point of view there is little difference between software that
crashes because its garbage and software that crashes because it is in early
stage of development but otherwise a good solution.

Lennart should write more robust software and maintainers should do more QA
when doing this type of system-wide changes.

~~~
danieldk
I agree very much with the points that you are making.

It would also help if small parts of a system would be replaced at a time.
Replacing daemon/process supervision, login handling, logging, network
configuration, etc. all at the same time in distributions that are used by
millions of users is quite risky.

~~~
digi_owl
Sadly the best you will get out of the systemd camp is "tough luck, should
have joined from the start to avoid the pain".

------
FeepingCreature
I'd probably respect SystemD a lot more if it measured itself against a modern
init system like Gentoo's OpenRC instead of pretending it's invented
dependency handling.

[https://wiki.gentoo.org/wiki/Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Comparison_of_init_systems)

> OpenRC provides a number of features touted as innovative by recent init
> systems like systemd ...

~~~
otabdeveloper
Systemd isn't an init system, it's a service (a.k.a daemon) management daemon.
Its primary purpose is to restart and diagnose failing daemons cleanly.

Systemd won for one simple reason: it's the only tool that accomplishes this
task without bugs. We've been running daemontools for almost a decade in
production, and it's a nightmare of bugs. Very glad to be finally switching to
systemd.

~~~
semi-extrinsic
> Its primary purpose is to restart and diagnose failing daemons cleanly.

If this is true, and speaking as a systemd user for close to five years now,
it universally sucks at its primary purpose.

Specifically, whenever a service fails, I've lost count of the number of times
systemd has barked out useless errors with 200 lines that boil down to
"service has entered failed state". Whenever a systemd service fails, odds are
better than even I have to spend two hours debugging why by enabling internal
logging in that service, running in debug mode etc.

Like when I tried to switch to networkd, and had the wrong password for a wifi
I was connecting to, networkd never told me this in any way I could find. Had
to go back to the old solution (after an hour of pulling my hair out) before I
realised the password was wrong.

~~~
Mic92
Networkd does not handle WLAN authentication. This is the job of
wpa_supplicant, which is the defacto standard on linux in every setup until
maybe iwd from Intel takes over.

~~~
semi-extrinsic
Yeah, but I'm sure you agree networkd should propagate errors from
wpa_supplicant such that they reach the user, instead of piping them to
/dev/null (not literally, but you get my point)?

~~~
lksgkjhsgkjh
networkd doesn't know about wpa_supplicant, just as it doesn't know about
openvpn, vpnc, ...

If you want a network manager that does know about those and might give more
helpful error messages if they fail, use for example NetworkManager.

~~~
dsr_
Then perhaps networkd should be dropped, because:

repeat after me:

everything eventually fails.

How can you tell when a programmer has graduated from "completely new at this"
to "has some valuable experience"? That point comes when they stop assuming
success.

Check for error and do something useful with the returned value.

Write tests yourself.

Fail gracefully.

Log status, so you know what was happening just before it failed.

Set reasonable timeouts on external processes.

Systemd is written from the perspective of a laptop user who will hand over
the whole thing to a support tech when things go wrong. This is antithetical
to the spirit of UNIX, which is not "write programs with one purpose that
chain together well".

The spirit of UNIX is this: At any time, a user on the system may decide to
become a developer or a sysadmin. The tools and information they need should
be available.

~~~
lksgkjhsgkjh
`ifconfig`, `ip`, `dhclient` or Debian's `ifupdown` don't care about errors
from wpa_supplicant either. Let's drop them too?

Or actually all of them (including networkd) work fine, but are not the right
tool for every usecase.

~~~
merb
well ifconfig (net-tools) actually is not pre-installed for fedora > 19 or 20,
basically because not everybody uses them and ip addr gives a more simple
output for (most users)

------
sebcat
> The justification for storing logs in a binary format was speed and
> performance, they are more easily indexed and faster to search.

Are there any benchmarks for this? I don't know why, and I may be doing things
wrong, but journalctl -lu <unit> \--since yesterday in our prod env takes a
couple of seconds before I see any output, while a (z)grep on a date rotated,
potentially compressed log file on a non-journald system is generally
instantaneous.

On a side note, I really like machine parsable, human readable logs, and I've
never had any speed or performance issues with it when dealing with volumes of
hundreds of millions of log entries, though that may be because I don't know
any better.

~~~
gens
Of course nobody benchmarked. Rarely are there programmers in OSS these days
that benchmark anything. (not nearly as common as those who claim "speed")

There was a bug though where the journaling was so slow it caused the whole
server to crash. (sorry, can't find it right now; something about them using
mmaped files and the access pattern was.. or something, interesting stuff:)

Binary logs _should_ be faster, in theory, and _should /could_ be as robust as
text logs (if not more), in theory. edit: note that GNU grep is insanely
optimized.

~~~
pif
> Rarely are there programmers in OSS these days that benchmark anything.

Please, don't release such a bold statement without any source. Please!

~~~
gens
There is the object of this discussion, systemd, that has always been about
"starting things in parallel" to make it "boot faster" but there has __never
__been a _proper_ benchmark (the distrowatch guy said, when asked, that he
didn't notice any difference; i didn't see a _proper_ benchmark anywhere by
anyone). The kdbus proponents that were active on lkml at the time of
increased drama (including the devs) also never did a _proper_ performance
evaluation. It was Linus who had to actually run perf on dbus to (easily) show
the real reason why it is slow... I also remember commenting _en passant_ once
or twice about bad and/or biased performance testing. So that is my "source",
the relative lack of _proper_ benchmarks on blogs when they talk about
performance of a piece of software. At least this is how it seems to me, as i
did not email a bunch of programmers to feel around (innuendo not intended,
but funny so i'l leave it).

On the other hand some OSS projects (the various databases, for example) do
have posts/writings on performance. There are even some really in depth ones.

I'm fine with things being bloated (or just plain cpu slow) as that careless
coding lets people make some nice things (a big part of KDE, for example). But
i am not fine with people who publicly claim that their code is fast(er)
without doing _proper_ benchmarking. Hell if it was hard i wouldn't say
anything, but it is not (for C code at least).

Objectively most programs i use (and most people use, even without knowing)
can afford to be slow and eat much more memory then they should. Because most
programs just sit there doing nothing for the grand majority of their run time
(FF and sublime.., why do you send those msgs that use up 1-4% cpu ? i just
don't understand). (honestly i'm worried that they are lowering(raising?) the
performance baseline. but that's just predictions of future, voodoo, spirit
animals showing the flow of chi or something)

PS Sry for the dumb rant. I like the topic of performance.

------
alyandon
At first I didn't care much for the idea of having to learn yet another init
system but as I had to write ansible automation stuff for services on Centos 7
it was kind of required that I have some basic understanding of systemd. I
have to say now that I'm more familiar with it it has begun to grow on me.

There is something subjectively nice to me about running systemctl status and
seeing a nice, clear picture of what the current state of services are on a
system, being able to control the life cycle of a service including having
systemd monitor and restart it, not having to deal with improperly written
init scripts, etc.

Stockholm Syndrome perhaps?

~~~
astrodust
The _idea_ of systemd isn't bad. What's annoying is the friction involved in
using it.

It's just a shade too ornate, a little too magical, in both cases only by a
small degree, but it's an important one.

Creating a workable systemd init script is actually pleasant. Getting it
running is easy. Checking for errors with status is nice, but searching the
logs is annoying.

pm2 ([https://github.com/Unitech/pm2](https://github.com/Unitech/pm2)) has a
neat feature where you can watch logs easily, someting that systemd should
totally steal and pack into journalctl, like "systemctl logs sshd" shows it in
real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f"

~~~
nvarsj
I'm not sure how you could write this with a straight face. Systemd has
friction, but writing init scripts doesn't? Are you kidding me? Have you ever
had to write init scripts for production servers? Writing systemd unit files
is entirely more straightforward and simple than any init script hackery. And
how is "journalctl -u sshd -f" not straightforward? Systemd has its issues
sure, but your comment is pure FUD.

~~~
yjftsjthsd-h
Ad hominem aside...

"journalctl -u sshd -f" is not straightforward because it's a _redundant_ new
command when I already know grep and tail. Small tools handling text is a
wonderful way to make a system easy to learn and powerful to use, and we're
just throwing that out.

~~~
majewsky
You still have it good. I'm already flipping forward and backward between
tail/less on the legacy systems, journalctl on the current systems, and
`kubectl logs` on the new systems.

~~~
jononor
Got myself some "docker logs" and "heroku logs" also...

------
tannhaeuser
Best thing of systemd is that it's putting people behind alternate systemd-
free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come
along nicely.

I can tolerate systemd on desktops as long as I don't have to deal with it.
The moment it craps out with Java-esque error traces in binary logs I'll
install Slackware (or is there a modern desktop Linux without systemd I'm not
aware of?).

Other than for desktops with complex run-time dependencies (WLAN, USB devices,
login sessions), what are the benefits of systemd for servers that warrant a
massive, polarizing, tasteless monolith which puts you up for endless patches
and reboots, especially in a container world? (Re-)starting and stopping a
daemon isn't rocket science; it's like 10 lines of shell code.

~~~
dijit
SystemD was so polarizing for me, I was a Fedora user and RHEL user for work-
but it started consuming everything and giving _really_ bizarre issues... I
tried reaching out and explaining to people that it wasn't working in the way
I expected or, asking them to point me towards the docs so I can at least
learn how to use journalling properly so it doesn't hide issues from me.. and
was met with some hostility.

When I asked to disable binary logging entirely because it kept getting
corrupted and was opaque I was met with "Unlearn your old ways old man"-style
responses and "You can just log to rsyslog _too_ ".. No, I want it disabled..
I don't have a desire to log twice..

It was then I realised I was at the mercy of systemd, they can push whatever
and reject whatever and I'm completely out of control- I cannot introspect
their service manager effectively, it's non-deterministic. It just reeks of
hubris from the maintainers. It does _mostly_ the right thing for _most_
people, and they compare it to sysvinit which admittedly needed love. (and,
was not a process manager, was only a process starter).

So, I adopted *BSD on the server. And christ is it wonderful.

I still use Arch/SystemD on my desktop at home, because it's actually pretty
useful on laptops/desktops. But I swore a vow never to manage a server with
SystemD on it.

I'm still runing RHEL6 at work, for the next OS, I'm pushing my very large
corp to adopt FreeBSD as an alternative. That's a fairly large amount of money
that Red Hat will lose and I don't particularly feel bad about it.

They forced my hand.

~~~
tannhaeuser
If you're deep into Fedora/RHEL, maybe you can make sense of the fakesystemd
situation [1]. Supposedly fakesystemd helps to provide at least a systemd-free
Docker container. I'd definitely hate to see CentOS/RHEL go away (which I've
come to appreciate as a predictable, if conservative, Linux distro in the
past).

[1]:
[https://bugzilla.redhat.com/show_bug.cgi?id=1118740](https://bugzilla.redhat.com/show_bug.cgi?id=1118740)

------
CaptSpify
I'll put my opinion in the middle ground with systemd as well. I like a lot
about it, and I dislike a lot about it. I really think the best thing they
could have done would have been to make it modular. If people could just turn
off the "features" that they don't want, there wouldn't be so much bitching
about it.

Instead they keep trying to shove everything into one giant pile, and don't
understand why people get upset.

~~~
srslack
You'll find that there's pretty much nothing you can't outright disable,
except for journald. journald needs to be running, but you can turn off the
binary logging and redirect everything to syslog. systemd itself is a
collection of system daemons, as well as small programs to interact with those
daemons, and almost all of them are disabled by default. That's my experience
on Arch, and they adhere strictly to upstream defaults. If that weren't enough
you could simply leave out the daemons you don't like at compile time.

~~~
JdeBP
> _you can turn off the binary logging_

Every time that people write that they tell other people who do know systemd
that they do not know it. The journal cannot be turned off. Making it be
stored in files in /run/log/journal/ instead of in files in /var/log/journal/
_is not turning it off_. It's making it non-persistent so that it doesn't last
across system restarts, delegating the job of writing persistent logs to post-
processing services that (nowadays) read the journal using its systemd-
specific database access facilities. Ironically, making it not be stored in
any files at all would actually prohibit the post-processing services from
working, as they would have nothing to read and to process into their own
formats.

* [http://unix.stackexchange.com/a/332315/5132](http://unix.stackexchange.com/a/332315/5132)

~~~
srslack
>they tell other people who do know systemd that they do not know it.

I appreciate the concern, thanks.

>The journal cannot be turned off.

The persistent binary logging is turned off, which is what people bitch about.
Obviously, many of systemd's monitoring features are tied to the journal, and
as stated journald still needs to be running, obviously writing to a non-
persistent journal for these and forwarding logs (if specified.)

>delegating the job of writing persistent logs to post-processing services
that (nowadays) read the journal using its systemd-specific database access
facilities.

It's true that syslog-ng pulls messages from the journal, whereas syslog
implementations that are not aware are provided with them over a compatibility
socket, but this is a performance optimization, to reduce system overhead. Not
really an important distinction.

The context was turning persistent logs off and switching to on-disk and
persistent text logs with syslog. If you really wanted to nitpick: dbus and
udev are totally non-optional.

~~~
majewsky
Is udev optional on _any_ Linux system? (Okay, you probably don't need it on
embedded, but then you likely won't want to afford systemd anyway.)

~~~
JdeBP
Yes. For starters, vdev and mdev exist.

* [https://news.ycombinator.com/item?id=11302557](https://news.ycombinator.com/item?id=11302557)

* [https://news.ycombinator.com/item?id=11609980](https://news.ycombinator.com/item?id=11609980)

~~~
lksgkjhsgkjh
vdev was already given up again:

> This system is mothballed.

From its Github page at
[https://github.com/jcnelson/vdev](https://github.com/jcnelson/vdev)

------
msimpson
Personally, I love Systemd for Web development as it makes the job of managing
Node.js projects a breeze. I simply pack a Systemd unit file into a project's
repository as part of its multi-environment configuration and construct
deployment tasks to copy, enable, then start the unit file.

1\. Copy <unit.service> to the sever, which looks like:

    
    
      [Unit]
      Description=<name> Service
      After=network.target
    
      [Service]
      Restart=always
      StandardOutput=syslog
      StandardError=syslog
      SyslogIdentifier=node-<name>
      User=<user>
      Group=<group>
      WorkingDirectory=/srv/node/<name>/current/
      Environment="NODE_ENV=production"
      Environment="PORT=2580"
      ExecStart=/usr/bin/node server.js
    
      [Install]
      WantedBy=multi-user.target
    

2\. Enable the unit file in place:

    
    
      sudo systemctl enable /srv/node/<name>/config/<unit.service>
    

3\. Start the unit file:

    
    
      sudo systemctl start <unit.service>
    

And, of course, destroying that deployment is just as easy.

------
agumonkey
Systemd ideas I'm all for but it only hints at linux lack of clean abstraction
power. sysvinit was full of redundancy; apparently BSD found a way to make a
thin abstraction layer to make init files clean.

Bash isn't "good" at hinting proper abstractions, I rarely see talks about
this, maybe gurus can see through the rain.

I keep seeing a place for a tiny lambda friendly intermediate layer .. Just so
you can compose properties of your services like clojure ring middleware.

    
    
       (->
         (path "/usr/bin/some-service" "arg0" ...)
         (wrap :pre (lambda () ...)
               :post (lambda () ..))
         (retry 5)
         ...
         (timeout 5))
    

Is this ugly to your eyes ?

ps: the idea is that (retry 5) is a normal language function, and not a
systemd opaque built-in, you can write your own thing, and the most used can
go upstream. Hoping to avoid the sysvinit fragility and redundancy.

~~~
chubot
Shell and bash are actually excellent at this, but people don't like writing
shell scripts. This is just process chaining. Take a look at DJB's or the more
modern runit for init toolkits that compose.

[https://cr.yp.to/daemontools.html](https://cr.yp.to/daemontools.html)

[http://smarden.org/runit/](http://smarden.org/runit/)

Here is a bash function that retries N times:

    
    
        retry() {
          local n=$1
          shift
          for i in $(seq $n); do
            "$@"
          done
        }
    
        retry 5 echo hi
        

Then you can compose with a timeout function, which already exists:

    
    
        timeout-demo() {
          timeout 0.1 $0 retry 5 echo hi
        }
    

You can pass the names of other functions as pre and post hooks as well.

[https://www.gnu.org/software/coreutils/manual/html_node/time...](https://www.gnu.org/software/coreutils/manual/html_node/timeout-
invocation.html)

Shell has a very forth-like quality to it, and Forth is sort of like a
backwards Lisp as well (postfix rather than prefix).

~~~
bazurbat
Isn't it just repeats the command 5 times instead of retrying?

IMO Bash with it's multitude of annoying quoting and field splitting rules,
many irrelevant features focusing on interactive use, and error handling as an
afterthought is just wrong choice for writing robust systems. It's too easy to
make mistakes. And it still works only in the simplest cases, until somebody
evil deliberately pass you newline delimited string or something with patterns
which expands in unexpected place, etc. Properly handling those cases will
make your script ugly mess. Actually I find the mental burden when writing
shell scripts is very akin to programming in C.

~~~
JdeBP
> _Bash with it 's multitude of annoying quoting and field splitting rules_

So don't use the Bourne Again shell. After all and to start with, if you live
in the Debian or Ubuntu worlds, your van Smoorenburg rc scripts have not been
using the Bourne Again shell for about a decade.

There's no reason at all that run programs need be written in any shell script
at all, let alone in the Bourne Shell script. Laurent Bercot publishes a tool
named execline that takes the ideas of the old Thompson shell ("if" being an
external command and so forth) to their logical conclusions, which is far
better suited to what's being discussed here. One can also write run programs
in Perl or Python, or write them as nosh scripts.

* [http://blog.infinitenegativeutility.com/2015/2/celebrating-d...](http://blog.infinitenegativeutility.com/2015/2/celebrating-daemontools)

------
Karrot_Kream
I feel like at some point, news aggregation sites will need moratoriums on
this topic. Systemd is an architectural decision with very philosophical
effects, so by its very nature be very divisive. I'm, personally, not a fan at
all of systemd, but am tired of seeing these stupid arguments everywhere all
the time.

There are plenty of places to find competent summaries of both the technical
and political arguments for and against systemd and we don't need yet another.

~~~
djsumdog
I don't feel they should. These are arguments I haven't heard before either
and I'm glad to see more of these weird cases laid out.

I run Gentoo (OpenRC) and Void (Runit) on my own systems, and although I do
like both of them, I find the total lack of alternatives to the systemd
ecosystem troubling.

As a package maintainer, I do like being able to create rpms/deb files and
only needing one standardized init script, so there is are a few advantages to
systemd, but not many. It's complexity makes it difficult to create drop in
replacements (work has stopped on uselessd and others).

There needs to be more community support for distros like Void and real
alternatives. Articles like this encourage that kind of thinking.

~~~
lisivka
Why not to write generator of init scripts from Systemd unit files? Unit files
are well documented for typical options and are easy to write.

~~~
JdeBP
Ahem!

* [http://jdebp.eu./Softwares/nosh/worked-example.html](http://jdebp.eu./Softwares/nosh/worked-example.html)

* [http://unix.stackexchange.com/a/200281/5132](http://unix.stackexchange.com/a/200281/5132)

* [https://www.mail-archive.com/supervision@list.skarnet.org/ms...](https://www.mail-archive.com/supervision@list.skarnet.org/msg01227.html)

------
colemickens
Why would you run the Exec command through systemd-escape? The help text says
that's for the NAME of the unit... Am I missing something?

Also, I'm failing to think of a scripting purpose that requires you to place
non-trivial bash directly in a systemd unit that couldn't be solved by writing
out the script somewhere and just invoking the script in the unit.

~~~
naftulikay
> Now agreed, if your workflow demands that you embed a Bash while loop in a
> unit, you’re already in a bad place, but there are times where this is
> required for templating purposes.

It's right there in the post. I have indeed had to do something like this in
the wild to run a Docker container with special needs.

~~~
colemickens
I don't see how "templating purposes" answers the question. I deploy services
on VMs that need to parameterized and I can parameterize via templating a
written-to-disk shell script that is then just simply executed in the unit...
or I can have more dynamic parameterization and use environment variables and
Environment= lines in the unit. The latter solution means the substitution is
effectively happening in the same place as if they were inlined parameters, so
I can't imagine a scenario when it wouldn't be workable.

------
awinder
I don't know if I'm just crazy but I did enjoy working with upstart for the
brief time that I did, much more so than systemd or initv.

~~~
nictrix
I agree, Upstart was great for most things and was simple to understand.
Though I ran into some difficult fork, exec issues for certain processes. I
sometimes had to run a wrapper to use upstart, but those seemed to be edge
cases.

I'd prefer if we stuck with Upstart and improved on it, though it already
seems like a distant dream.

~~~
digi_owl
I sometimes wonder if edge cases are inherently fractal. take care of one and
two more spawn.

Thus when i see some dev talk about exorcising edge cases because of user
friendliness i see them preaching a fools errand.

------
peterwwillis
The problem with systemd is not that it is "bad". There's a lot worse software
out there. Systemd is relatively competently programmed. And it's even useful!

The problem with systemd has _always_ been that it forces you to do everything
the systemd way, and usually to use its tools. It goes against everything that
has helped GNU/Linux become a great system: that it wasn't really one system.
It was bits and pieces, and you could add them together however you wanted to
get something you liked.

Systemd is the opposite. It is inflexible and clunky, monolithic and
proprietary, binary and difficult. Everything has to be made to work with it,
not vice versa. It doesn't follow any of the old conventions that made it
simple to combine one tool with another. I can compare it to Windows, but I
feel like that would be an insult to Windows' usability.

If this one single fact was different, everyone would love systemd, because it
has plenty of useful features. But because it is designed specifically to
please a single quirky user, people hate it.

~~~
reflexive
> Systemd is the opposite. It is inflexible and clunky, monolithic and
> _proprietary_

The other points can be debated, but please don't call it proprietary. It is
free software as in "freedom" (LGPL).

~~~
peterwwillis
It is indeed proprietary because it does indeed have an owner. But I use the
word in the context of its design and implementation, which is basically that
of the not so benevolent dictator, or the possessive or territorial.

~~~
reflexive
> It is indeed proprietary because it does indeed have an owner.

You are using the term _proprietary_ incorrectly, probably out of simple
ignorance. The software does not have an "owner" who has power of the users;
the LGPL means all users have complete control over the software.

Please read this carefully before spreading more misinformation:

[https://www.gnu.org/proprietary/proprietary.en.html](https://www.gnu.org/proprietary/proprietary.en.html)

~~~
peterwwillis
I'm aware of the definition of proprietary software. I'm not using that form
of the word.

------
Esau
I don't care for SystemD for the same reasons that I don't like MacOS's init
system: it an opaque, confusing mess.

~~~
kalenx
As are most Bash init files with InitV... At some point we should consider
that the init system as a whole (including the configuration scripts for each
daemon) _is_ complicated and often confusing. In this regard, writing
something like SystemD to elegantly handle most of the usecases is actually a
good idea.

~~~
_red
Bash init files may not be particularly feature rich, but they are hardly
"complicated".

90% of every file is boilerplate built around: stop, start, status (after all
restart is just stop+start).

Proponents of SystemD can make some good points, but trying to claim init.d is
complicated comes across as desperate.

~~~
kl4m
And 90% of that 90% has that tiny modification that is a nightmare to debug.

~~~
lisivka
Use `set -x` or `bash -x script.sh` to trace shell script execution. Shell
scripts are easy to debug.

~~~
eropple
I call this to drop into an immediate repl at the point of invocation in a
language that doesn't hate me (Ruby):

    
    
         require 'pry'; binding.pry
    

This is, in fact, 2017. One might call it _the current year_. The stone knives
and bearskins of shell scripting have not kept apace with, like...anything
else in our industry. You might be comfortable with them, but that doesn't
make it easy, it means you have frayed countless synapses learning it.

------
throw2016
Systemd has a lot of attention and people working on it and it will eventually
become good enough for the vast majority.

But there were questionable tie-ins with various pieces like udev, consolekit
and even gnome that allowed Systemd to become defacto init. The call for a
kernel bus promotes a similar lock in with Systemd and this makes the use or
development of alternatives and choice difficult.

There are things like predictable network names which are useful for 1% of
users and are anything but predictable. Binary logging makes sense for the
security industry Redhat serves but again has no use for the 99% others who
anyway have to put up with it. There is a pattern of forcing things onto
everyone that make sense for a tiny minority.

The big problem is open source funding. No one is interested in just
supporting projects they benefit from. Acquisitions or hiring developers put
these projects and developers under the control of companies like Redhat.
Redhat has become a cathedral and a cathedral by sheer size and nature is
always interested in securing and furthering its own influence and interests.
When you allow such forces to become too powerful they will subsume the public
interest to their interest.

------
ausjke
The sad thing is, you do not really have a second option, yes I know some
distros say they have alternatives, but SystemD becomes the "preferred" init
system nearly everywhere now.

I just hope Debian to get rid of SystemD and return to whatever else. I know
I'm biased, just failed to find a reason to love SystemD, tried a few times.

~~~
hedora
I've found that devuan is a joy to use on my laptop.

I'm also rotating BSDs and open source solaris variants on to the home network
machines. (Switching to solaris to get rid of systemd would be overkill; I
switched to joyent triton for better containers and zfs...)

~~~
ausjke
Devuan has jessie in beta now, at the moment I have not given up on linux yet,
am going to try Devuan.

------
digi_owl
More and more systemd is becoming symptomatic of deeper divide within the
Linux "community".

The split being between those that embraced Linux for being a free, in both
senses, _nix unburdened by AT&T and running on commodity hardware, and those
that got to know it after the dot-com crash as the L in LAMP.

The former cares for Linux as a _nix, the latter could not care less about
_nix and may see it as a vestigial appendage that should have been amputated
long ago.

~~~
AnonymousPlanet
I'm not so sure if it really has that much to do with heritage. A lot of us
like the design principles you can see in Unix and that are pretty much absent
in systems like Windows NT. They very much reflect the conclusions I came to
after over fifteen years of building and debugging systems.

But, yes, I have the impression that a lot of Linux users would just as gladly
use a modern BeOS or a ReactOS, regardless of the underlying design.

And a lot of systemd criticism comes from people who are just averse to any
kind of change and maybe long for the bygone days of HP-UX and Irix.

~~~
digi_owl
There is change and there is change.

------
secabeen
I've never particularly liked init systems that restart jobs when they die.
Normally, I don't want daemons that crash to restart. They should die, be
caught by monitoring and the server bypassed. I would accept a single restart
but after that, there's clearly a problem, and the systems should fail, rather
than restarting the process again and again and again.

~~~
plorg
As a single user with a number of personal/hobbyist machines, I actually find
systemd annoying to work with for precisely this reason. If a daemon is
misconfigured and fails to launch several times in a row, it inevitably
triggers the systemd "too many retries" error, after which systemd will refuse
to start the daemon until some timeout has expired or the counter is cleared.
This makes troubleshooting more difficult and frustrating.

~~~
kinghajj
Funnily enough, just dealt with a bug caused by this at work. The small PC
would boot before the cellular modem had an Internet connection. Services that
communicate via MQTT would immediately attempt to reach the broker, and throw
an exception. My quick fix was just to add "RestartSec=5" so that the faulted
state would never be entered.

~~~
kasabali
Ironic considering how systemd developers brag about eliminating race
conditions and sleep calls from init scripts.

------
pkaye
One of the things I like about systemd is you can get a graph of the boot time
along with critical path via the following: systemd-analyze plot >boot.svg

------
weberc2
> Admittedly, it requires an environment file

I know almost nothing about systemd, but you can define environment variables
inline instead of in a file: `Environment=ENV_VAR=value`.

------
svennek
Most people I hear having problems with Systems is either on Redhat or Debian
- not realising the both are mangling systemd badly. RHEL took in systemd way
too early and are missing a lot of needed functionality. Also the have an
ungodly amount of patches on top - so much you could argue it should be named
redhatd instead. Debian just chooses to take the worst possible middle
position due to politics. All of the disadvantages from systemd, but not
really any of the great stuff as systemd units often just start shellscripts
due to compatibility.... If you want to try systemd in all its glory try Arch
or something downstream from it... I for one think that systemd has made my
admin-life so much better ..

~~~
AstralStorm
I am running systemd on Gentoo. (like Sabayon) While some of the features are
nice, it is a royal pain to upgrade due to intertwined deps and forced
restarts.

And it doesn't do anything OpenRC couldn't do, in fact its journald is a pain
which had to be worked around. OpenRC way of doing socket activations and dbus
activations also works slightly better (in case something crashes) It does
parallelism just as well, service dependencies too.

Gentoo does not mangle anything related to systemd unlike the mentioned
distributions.

~~~
svennek
Yeah, Gentoo is quite nice in that regard, but isn't it still focussed on
openrc? I was a ten plus years gentooo user before I switched to Arch (mostly
because I got fed up with compiling)

~~~
jakeogh
OpenRC is the first option in the install guide, but you can choose systemd. I
cant think of a good reason to do so.

------
_ZeD_
(from tfa): "Now, let us turn our attention to the benefits that systemd
brings us. I believe that these are the reasons that all Linux distributions
have adopted systemd."

 _ahem_ slackware has not adopted systemd

~~~
yjftsjthsd-h
Nor has Gentoo adopted it as the primary system (and, in fact, OpenRC remains
a favorite alternative).

------
Sir_Cmpwn
I've found runit to be the best (but not perfect) as far as init systems go.
Check it out.

------
kasabali
Yet another systemd post which

\- Handwaves real criticisms and instead tries to look like an objective
writing by presenting a trivial issue

\- Have no idea about advances in sysvinit in the last decade that allowed
support for parallel boot and dependency relations (and which was supported
natively on mainstream distribution)

\- Totally ignores the other "modern" and _widely_ used init system and
instead compares systemd with sysvinit of 80's (which wasn't used by any
mainstream distro in that form)

\- Overrates process supervision features which were already as equally as
easy to use with supervision suites like runit (IMHO even easier)

Meh, what did I expect? Bandwagon is going full speed.

------
z3t4
My main complain about systemd is that it does not log the stderr stream !!

~~~
yrro
It does log the standard error stream. The default value of StandardError= is
inherit, which will cause stderr to go to the same place that stdout goes,
which by defaults to journal. This is documented in systemd.exec(5).

If not overriden in an individual service's unit file, perhaps you have set
DefaultStandardError= in /etc/systemd/system.conf?

~~~
z3t4
The problem is that it doesn't store "unit" meta-data for stderr, so you can
not see stderr logs with journalctl -u _nameOfUnit_ or systemctl status
_nameOfUnit_

~~~
yrro
I do not find this to be the case. Right now I'm looking at the journal and
observing the existence of _SYSTEMD_UNIT fields for messages that have been
written to a process's standard error stream.

~~~
z3t4
Can you see them when you run journalctl -u nameOfUnit or systemctl status
nameOfUnit ? I'm running Ubuntu server.

~~~
yrro
Yup. It is possible that your service is buffering output before actually
writing it to the standard error stream. Try attaching to it with strace -e
write PID and observe whether it is actually calling write(2, "some
message"..., somenumberofbytes).

To approach this from the other direction, try this program:

    
    
        import sys, time
    
        while True:
            print('test out', flush=True)
            print('test error', file=sys.stderr, flush=True)
            time.sleep(5)
    

With this service:

    
    
        [Service]
        Type=simple
        ExecStart=/usr/bin/python3 /tmp/test.py

------
nailer
Does systemd have a network protocol like syslog, i.e. is there a native way
to send logs for a particular unit/service to a remote machine?

Everything I find just says to install syslog, which surprises me.

~~~
JdeBP
Would native actually be your preference, though? Or would you really prefer
tools that spoke existing protocols like RELP?

~~~
nailer
native would be my preference as I'd rather avoid installing any software at
all. Protocol will be HTTPS, format will be
[https://www.freedesktop.org/wiki/Software/systemd/json/](https://www.freedesktop.org/wiki/Software/systemd/json/)

------
nvarsj
I get the feeling anyone who complains about systemd is just a hobbyist
jumping on a hate bandwagon. For anyone who manages production systems,
systemd is a godsend compared to the homegrown-per-distro shell based init
systems.

~~~
msimpson
Did you actually read the article or just these comments?

