
The Tragedy of Systemd [video] - DyslexicAtheist
https://www.youtube.com/watch?v=o_AIw9bGogo
======
antirez
The tragedy of systemd is that it's the wrong solution to a real problem.
Because most people against systemd will keep saying that the old init system
was ok, they don't move forward trying to provide a true alternative. So
systemd became a standard despite the issues, because it solves certain real
problems that people have, even if not great.

~~~
kfwhp
systemd became a standard because the guy works at Red Hat so he can make
GNOME require it (there is no way to use GNOME without systemd; distros that
allow that such as Gentoo do so by patching GNOME, which is costly.)

I agree that a more modern init system is necessary, but the idea of systemd
is meh and the implementation is subpar.

~~~
kevin_b_er
The intentional and willful breaking of screen and tmux was to fix a GNOME bug
of GNOME not closing up as it should when the user logs out, so systemd was
changed to mass kill processes. The interplay between GNOME and systemd in
backroom dealings is a major pain point.

~~~
kbenson
I think that's an oversimplification. There are definitely cases where some
thing started as a daemon under a user session, graphical or not, should be
killed to be safe. For example, ssh-agent.

There are other things that are meant to be left around, as that's their
purpose, such as screen and tmux.

I would say the safe solution would be to kill everything in the user session
at _multiple levels_ (GNOME, and user session management demon like logind,
etc), and to provide a defined safe way for the very few programs that want to
stick around to do so. That seems like what systemd came up with as well.

------
timw4mail
The tragedy of having to watch a youtube video instead of reading a
transcript...

~~~
loeg
[https://news.ycombinator.com/item?id=19023232](https://news.ycombinator.com/item?id=19023232)

LWN does a reasonably faithful summary.

------
ardy42
Previously:

LWN article:

[https://news.ycombinator.com/item?id=19023232](https://news.ycombinator.com/item?id=19023232)
(1/29/2019)

This talk:

[https://news.ycombinator.com/item?id=19157293](https://news.ycombinator.com/item?id=19157293)
(2/13/2019)

Another youtube version of it:

[https://news.ycombinator.com/item?id=17778202](https://news.ycombinator.com/item?id=17778202)
(8/16/2018)

------
syn0byte
I ask this in every systemd thread but I genuinely would love a real answer.
Can anyone give me exact real-world examples of where systemd is objectively
better suited than any number of other init systems?

The fact that I still have yet to see any such examples in the last half a
decade seems pretty telling. Wouldn't and shouldn't there be tons of such
examples given the rhetoric?

~~~
foldr
It makes it a lot easier to set up a service than System V init. Writing a
service file is much easier and less error prone than writing shell scripts.

~~~
JdeBP
syn0byte explicitly said "any number of other init systems", and was clearly
trying to avoid people trotting out, as you and several others have, the tired
old fallacy, called out by the Uselessd Guy long since, of assuming that only
systemd and van Smoorenburg init+rc exist ...

* [http://uselessd.darknedgy.net/ProSystemdAntiSystemd/](http://uselessd.darknedgy.net/ProSystemdAntiSystemd/) ([https://news.ycombinator.com/item?id=8488235](https://news.ycombinator.com/item?id=8488235))

* [https://blog.darknedgy.net/technology/2015/09/05/0/](https://blog.darknedgy.net/technology/2015/09/05/0/)

* [http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...](http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html)

... and then calling the latter "System V init", when AT&T System V had
actually adopted a new system with separate system and service management
several years before Linux was even invented.

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

~~~
foldr
I took syn0byte to be asking for an example of an init system that systemd is
better than. I can't really see any other interpretation of their comment.

>and then calling the latter "System V init",

This is what everyone calls it in the context of Linux init systems. You may
not like that particular piece of terminology, but please don't give me a hard
time for following the standard usage.

~~~
syn0byte
"any other init system..." originally included "...besides an ancient SysV
strawman." but I removed it because it seemed overly snarky.

Having written and dealt with both; It's about equal in my time and effort to
write either in sh or windows ini/'unit' files.

~~~
foldr
If you claim that System V init is just as good as systemd, then it is a
relevant comparison rather than a straw man, no? In many cases there were a
substantial number of people who wanted to keep System V init rather than move
to systemd (e.g.
[https://wiki.debian.org/Debate/initsystem/sysvinit](https://wiki.debian.org/Debate/initsystem/sysvinit)).

System V init wasn't an ancient straw man for Debian users. It was the init
system that systemd replaced.

------
ilovecaching
What problems do people have with systemd? I actually think it’s pretty great.
They also made some tools like busctl that are really nice for Linux
developers.

~~~
isostatic
Something that annoyed me 10 minutes ago

Old fashioned way, when I restart apache having made a typo:

    
    
      Output of config test was:
      AH00526: Syntax error on line 2 of /etc/apache2/sites-enabled/mysite.conf:
      Invalid command 'blah', perhaps misspelled or defined by a module not included in the server configuration
      Action 'configtest' failed.
    
    

Now

    
    
       [....] Restarting apache2 (via systemctl): apache2.serviceJob for apache2.service failed because the control process exited with error code.
       See "systemctl status apache2.service" and "journalctl -xe" for details.
        failed!
    

The former is far more informative

~~~
gh02t
I mean I agree that it should just show you the output of "systemctl status"
in the error message, but your comparison isn't entirely fair. The commands
systemd error message give will show you the same thing as the generic sysv
output.

~~~
isostatic
But it's that type of unhelpful behaviour that leads to dislike and
accusations of arrogance (how dare you type a command that doesn't have the
word "systemd" in it)

~~~
kbenson
Is it unhelpful, or just different? In the case of systemd, isn't it logging
all the errors in the journal so you can see prior occasions it had a problem
and errored? What is the error output in the jouirnal? Is it better, worse, or
the same?

Systemd makes the process two steps, which you think is worse, but you've
failed to address whether the possible benefits of those two steps (error
retention, possibly more or different levels of error reporting) have been
taken advantage of, and how that looks.

There's a difference between something being worse and just different. So far
all I've seen is different, and _possibly_ worse, but you've left out the
information that would be required to determine that.

~~~
isostatic
When you're using an interactive shell to restart a process, and it fails, why
wouldn't you want it to tell you _why_ it failed.

    
    
      sudo systemctl restart apache2.service || systemctl status apache2.service
    

does the job, it's just ridiculous to seperate a system that used to be
helpful.

Of course if you run sudo systemctl restart apache2.service You get no visual
indication it's worked

    
    
      sudo /etc/init.d/apache2 restart
      [ ok ] Restarting apache2 (via systemctl): apache2.service.
    

tells you it worked, at least on this ubuntu 1804 machine.

This regressive change in behaviour (taking away pertinent information for no
obvious benefit) leads to assumptions being made that things are getting worse
for normal people. This view is then backed up by the volume of "defending
systemd" statements that seem to stem from "scripting is hard".

People get turned off before they even begin to understand what systemd is
trying to do, not because of core reasons, but because of one of the first
interactions the average person has with systemd is to make their life harder.

~~~
kbenson
> This regressive change in behaviour (taking away pertinent information for
> no obvious benefit)

There is a benefit. The benefit is that it's logged, always, and through a
mechanism that is the same for every process. It's a trade off. We can argue
whether it's a worthwhile trade off, or one that even really needs to exist
(is there a reason they don't immediately show an error? I don't know), but to
say there is no obvious benefit even after I pointed out this specific benefit
in my prior comment is odd.

> People get turned off before they even begin to understand what systemd is
> trying to do, not because of core reasons, but because of one of the first
> interactions the average person has with systemd is to make their life
> harder.

Any change from what existed previously that requires a different way of doing
something, whether ultimately better or worse, makes the user's life harder in
the short run since they need to learn something new.

That's not to say that's all that's happening here. There appears to be a
regression in usability in at least one aspect. That said, I sort of
understand why they didn't make it output that info. There have been plenty of
times in the past for where sysV has reported a service started, but it
actually failed very shortly after start. Generally, figuring out why can be
painful, because STDOUT/STDERR have been redirected (or likely sent to
/dev/null). Keeping a log of the stdout so you can see what happened on that
last service action (and not hope it was logged to a log file, which it
sometimes isn't...) is very useful. Outputting that the service started
successfully is _nice_. Outputting that it started successfully when it didn't
is misleading and more of a problem. Again, that's a trade-off, where it
appears they've decided to favor accuracy over convenience in this case.

~~~
loeg
> The benefit is that it's logged, always, and through a mechanism that is the
> same for every process. It's a trade off. We can argue whether it's a
> worthwhile trade off, or one that even really needs to exist (is there a
> reason they don't immediately show an error? I don't know)

Yeah, it seems feasible (and maybe a good default) for systemctl to dump out
the same last few lines it would for 'status' if an administrative request
fails. I don't know why this has to be a tradeoff; systemctl actions could
easily both log and print (some limited subset of) the log on error.

~~~
isostatic
Logging it is great, it's the fact the interface says "look in the log" rather
than doing it for you.

It's tiny annoying things like that which leave a bad first impression. Rather
than going "hey this system is great, it logs what it tells me", instead I'm
left thinking "this system isn't for people like me, it doesn't think I need
to know why it's broken"

First impressions are so important.

------
cr0sh
What I have come to believe is the "Tragedy of Systemd" \- and if I am wrong
on this, please let me know - is that it was a virtually unilateral decision
to make the change, by one person, without any input from others.

It was like all at one shot - here's this huge and largely non-transparent
init system created by seemingly one person who it felt like was shoving it
down everyone's throat. My way or the highway style.

That, on top of what felt/feels like a lack of transparency about how it works
(I could look at init scripts and understand them fairly easily and how they
worked together - systemd seems almost a mystery to me; I just have to trust
it works - so far so good I guess).

Maybe I am wrong on all of this - again, if I am (and there's a good chance I
am I feel) - please let me know.

~~~
JdeBP
You are wrong. Read
[https://news.ycombinator.com/item?id=14735100](https://news.ycombinator.com/item?id=14735100)
.

------
fridsun
I just must let this one thing out.

> 34:02 binary logs are not a bad thing as long > 34:06 as you have the tools
> to pull them apart

Really? Did he just "as long as" the biggest downside of binary log compared
to text log, that is way fewer tools work on a binary log due to its special
encoding?

With the same logic, flu viruses are not a bad thing as long as you are immune
to them.

------
Gby56
Great talk imo, my TLDR would be : > systemd is not the best it could be, but
it's there. > distros patting themselves on the back because they don't use it
means they haven't listened to actual needs and stayed behind. > death threats
over software that nobody else tried doing are ridiculous

~~~
mondoshawan
Don't forget the gaslighting with "software has bugs" and "you just dont like
change", while glossing over legit complaints about the outright narrow minded
design of the system that is actively harmful in some cases (systemd-
timesyncd, I'm looking at you).

Personally, the video made me rather angry because all he does is set up straw
men and knock them down using the same terrible pro-systemd arguments that get
trotted out every time someone has a legit problem with its design.Some of the
distros that use systems like runit and openrc are using those sustems because
systemd doesn't fit their technicals needs, and likely won't ever because of
designs that are made without community input.

Oh, sure, he mentioned the Debian developer resignations, but outright failed
to point out the _reason why_ they resigned: systemd was being railroaded into
the system as a political move rather than being judged on its technical
merits.

~~~
theamk
> Oh, sure, he mentioned the Debian developer resignations, but outright
> failed to point out the reason why they resigned: systemd was being
> railroaded into the system as a political move rather than being judged on
> its technical merits.

No. Ian resigned because he tried to ignore systemd's technical merits and
tried to used political moves (GR process) to to kill it. As a result, most of
Debian's _community_ told him to top messing around with politics. Ian's
resignation letter [1] explicitly says that:

> I should step aside to try to reduce the extent to which conversations about
> the project's governance are personalised. [...]

> The majority of the project have voted to say that it was wrong of me to
> bring this GR at this time.

[1] [https://lwn.net/Articles/621895/](https://lwn.net/Articles/621895/)

Please stop saying systemd was being railroaded. I have no idea what was going
on in Redhat (I do not follow their mailing lists), but at least in Debian, it
got on its own technical merits, and Poettering had no special influence
there.

(That is not to say it is without problems; there are plenty of them. Still,
the lesser of evils...)

~~~
loeg
> Please stop saying systemd was being railroaded. I have no idea what was
> going on in Redhat (I do not follow their mailing lists), but at least in
> Debian, it got on its own technical merits, and Poettering had no special
> influence there.

Systemd got in on its merits in Fedora as well. (It had to — no amount of
railroading is going to overcome something totally dysfunctional, and Fedora
was the first adopter.) As I recall, the transition was fairly smooth.

------
creshal
The real tragedy is that so many complain about systemd and insist it's awful,
yet nobody ever bothers to actually make a _better_ init system. It's either
1980s crap that's totally unsuited to modern environments, or systemd with all
its bugs and design flaws.

~~~
keypusher
No, the tragedy is that you didn't watch the video, because the author isn't
complaining or insisting that it's awful. Instead, he (a well-known FreeBSD
developer) goes through the history of init systems and offers some
justifications for why systemd is the way that it is, and what challenges
might need to be overcome to make a "better" init.

