The Tragedy of Systemd [video](youtube.com)
youtube.com
The Tragedy of Systemd [video]
https://www.youtube.com/watch?v=o_AIw9bGogo
96 comments
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.
I concur. Before systemd, I used supervisor because I wanted to avoid using any init system like hell.
Since systemd, I just do a service file.
So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.
I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos.
Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.
Since systemd, I just do a service file.
So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.
I'm sure all the power user complaints about systemd are legitimate, but I really don't care about those. I just want an easy way to setup custom deamon on ubuntu and centos.
Provide a better system, that solve those problems, and I'll use it. I really don't care as long as my problem is solved.
> So despite all its shortcommings, I now have a standard, well documented, init system that I can use accross all the distros I use, which happens to provide all the features I need.
Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?
Same couldn't be said about supervisor, the solution you already had running (well, maybe strike init)?
It's not installed by default on any distro. I don't want to install something as basic as an init system.
And it's not installed by default because it doesn't solve the problem of a service dependancy graph.
And it's not installed by default because it doesn't solve the problem of a service dependancy graph.
Sorry, but that first argument seems a bit random to me. Couldn't even use a proper editor like nano with that argumentation, having a usable editor available is after all also pretty basic.
I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).
I doubt that supervisor is not installed because of not solving something it evidently does not want to solve, but that argument at least looks valid to me. Just in case you are not aware, https://github.com/Supervisor/supervisor/issues/122 lists two solutions (wait_for_it.sh and a supervisor plugin that adds dependency resolution).
I think "basic" in this case means "integral to the system". Many people don't want to replace the init system, nor the desktop display system, nor an authentication system (e.g. PAM).
The more systems something sits under the more places there are for it to cause a problem because it doesn't work quite how the upper components expect. At a bare minimum, you'll often run into problems with the included package management system (and how it may reload systems for security purposes after patching) if you don't take care.
nano sits on top of everything, and the few things that might rely on it use a very standard and not very extensible interface (the EDITOR environment var). It's not really equivalent at all.
The more systems something sits under the more places there are for it to cause a problem because it doesn't work quite how the upper components expect. At a bare minimum, you'll often run into problems with the included package management system (and how it may reload systems for security purposes after patching) if you don't take care.
nano sits on top of everything, and the few things that might rely on it use a very standard and not very extensible interface (the EDITOR environment var). It's not really equivalent at all.
I'm not tring to convince you, i'm sharing my pov. Systemd is here because of pov like this, and people not liking it end up with it anyway because they fail to aknowledge others pov.
> proper editor like nano
Not sure what your point is (well ok, I am, and I agree), but you just lost
Not sure what your point is (well ok, I am, and I agree), but you just lost
systemd is far more than an init system though, it's a total rethink of how linux systems are controlled and managed.
Rewatch the first half of the video and imagine it was a bunch of random tools with proper names (like grep, ntpd, syslogd) etc, that had all been built separately but happen to nicely tie into each other, rather than "systemd-blah"
Rewatch the first half of the video and imagine it was a bunch of random tools with proper names (like grep, ntpd, syslogd) etc, that had all been built separately but happen to nicely tie into each other, rather than "systemd-blah"
>Because most people against systemd will keep saying that the old init system was ok, ...
There isn't and wasn't hardly anyone saying that. It is and was well known that there were better things out there than the hacked up sysV style init systems produced by the various Linux distributions.
This is a common strawman that seems to get rolled out any time any discussion involves systemd.
There isn't and wasn't hardly anyone saying that. It is and was well known that there were better things out there than the hacked up sysV style init systems produced by the various Linux distributions.
This is a common strawman that seems to get rolled out any time any discussion involves systemd.
A few of the authors of one of the Debian based distributions dropping systemd are friends of mine and all of them see things in that way, that the good old init is fine and there is no need to replace it. In the Facebook group where they use to stay the others I don't know first-hand seem to share this POV.
Nearly every systemd-disliking person I've personally spoken to, has trotted out that exact line about sysV init being fine.
It's not just a strawman, unfortunately. I wish it were.
It's not just a strawman, unfortunately. I wish it were.
And yet basically no alternative to systemd was produced by any of those people.
Does upstart not count as an alternative?
Upstart is older then systemd and it was mainly developed by Ubuntu who dropped it. After that is continued to exist as a project but its basically not used anywhere and id didn't continue to develop all that much.
I didn't mean to imply that it was built as a competitor to systemd, more that it exists as a different alternative. I'm aware of what happened with Ubuntu dropping it, and I think it's a shame, as I like it as a simple response to the problem.
Is upstart better in any way?
Upstart doesn't include implementations on NTP, DNS, DHCP, or anything that opens a network port. It does however allow parallel boots with dependency analysis for quick boots.
Systemd on the other hand seems to be trying to take over syslog, ntpd, dhcpd, named, and related with generally poorer implementations. Feature creep seems constant with systemd, for no particularly good reason.
Systemd on the other hand seems to be trying to take over syslog, ntpd, dhcpd, named, and related with generally poorer implementations. Feature creep seems constant with systemd, for no particularly good reason.
But it's not just replacing init - it's replacing a dozen other services including things like ntp or dns, and often it's replacing them with inferior solutions.
My understanding is that the reason it started replacing other services is that there's a dependency graph that ends up pulling them in, and very early in the boot process depending on configuration[1]. That, and in some cases the available solution did not support their needs[2] (which might have been solved better through upstream work, or maybe not, if the targeted project was slow or unwilling, I'm not sure).
1: https://lists.freedesktop.org/archives/systemd-devel/2014-Ma...
2: https://www.reddit.com/r/linux/comments/6kdcme/why_does_syst...
1: https://lists.freedesktop.org/archives/systemd-devel/2014-Ma...
2: https://www.reddit.com/r/linux/comments/6kdcme/why_does_syst...
Yes, that's a design problem due to what the systemd main author believes to be a good thing.
systemd can be used without most of these things. systemd as a project has other services in but those you can use or not use.
And the claim that they are 'inferior solutions' is just absolutely false in most cases. It often replaced horrible old tools that haven't been updated in 30 years. It often provides far better interfaces and tooling then the existing solutions.
And the claim that they are 'inferior solutions' is just absolutely false in most cases. It often replaced horrible old tools that haven't been updated in 30 years. It often provides far better interfaces and tooling then the existing solutions.
The DNS resolver seems to break DNS, the time system no longer acts as a server
This isn't necessarily a problem with the systemd project, it's more on the distros that bundle these service, but when you have the same branding across multiple systems, you have to take the bad with the good.
Had they called it "multidnsd" or "ntpclientd" then people wouldn't think "systemd sucks because when MyDistro 9 came along", they've blame multidnsd and let the systemd init system stand on it's own.
This isn't necessarily a problem with the systemd project, it's more on the distros that bundle these service, but when you have the same branding across multiple systems, you have to take the bad with the good.
Had they called it "multidnsd" or "ntpclientd" then people wouldn't think "systemd sucks because when MyDistro 9 came along", they've blame multidnsd and let the systemd init system stand on it's own.
I don't recall the DNS resolver actually breaking DNS without it being fixed. And I'm not sure why most systems need NTP to run as a server.
You can always disable them at runtime or during compile and use your own though.
You can always disable them at runtime or during compile and use your own though.
[deleted]
>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.
The problem with systemd it is not just an init system. Its network-state-aware, device-state-aware container launcher(nspawn), cron, logind and syslog implementation.
The scope creep of systemd is enormous, nobody asked for that when they wanted reliable daemons.
The problem with systemd it is not just an init system. Its network-state-aware, device-state-aware container launcher(nspawn), cron, logind and syslog implementation.
The scope creep of systemd is enormous, nobody asked for that when they wanted reliable daemons.
More or less this. Gummiboot is nearly pointless, and ntpd and resolved have both caused problems for me. As an init system, systemd is fine, but shipping these bad components while giving them the systemd "seal of approval" is dumb.
On the other hand, I've had no issues with logind and gdm. I've been interested in trying S6 but given it's quite easy to substitute out the bad parts of systemd, so I just haven't bothered.
Probably the biggest problem with systemd is that it's hurting BSD. Then again, gnome devs are having enough trouble getting things working on Linux... also binary format journals are so dumb. How have they not changed that?
On the other hand, I've had no issues with logind and gdm. I've been interested in trying S6 but given it's quite easy to substitute out the bad parts of systemd, so I just haven't bothered.
Probably the biggest problem with systemd is that it's hurting BSD. Then again, gnome devs are having enough trouble getting things working on Linux... also binary format journals are so dumb. How have they not changed that?
The tragedy of systemd is tight coupling. What makes Linux great is that I used to always have a choice - regarding what kernel I use, what editor, what shell, even what Init I use... Systemd changed all that. Distro makers gave up supporting alternatives because it would mean too much work. (I almost flipped out when I read somewhere they had to do it because of some Gnome-related component... I mean I don't care about Gnome, I don't even use X, but I have hundreds of servers to manage - now let's change everything because one guy said it's the only way...)
Nobody would make what Lennart did if we had a choice. Those who liked Systemd would use it, and the rest would use the init of their choice. As simple as that.
Nobody would make what Lennart did if we had a choice. Those who liked Systemd would use it, and the rest would use the init of their choice. As simple as that.
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.
I agree that a more modern init system is necessary, but the idea of systemd is meh and the implementation is subpar.
You make it sound like the systemd author was something the CEO of all Linux Distros.
The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd:
The maintainers of Arch Linux have given an explicit list[1] of the reasons why they decided to introduce systemd:
0) it is hotplug capable
1) we can know the state of the system
2) it is modular
3) it allows dbus/udev to go back to doing the task they are meant to do
4) we can reduce the number of explicit ordering dependencies between daemons
5) we get a lot of security/sandboxing features for free
6) systemd service files can be written and distributed upstream
7) systemd is a cross-distro project
8) logind will finally deliver on what consolekit was supposed to do
9) systemd is fast
systemd became a standard because Debian adopted it after a lengthy discussion, partially because big Debian users like Spotify expressed an interest in systemd.
https://lists.debian.org/debian-ctte/2014/01/msg00287.html
https://lists.debian.org/debian-ctte/2014/01/msg00287.html
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.
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.
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.
The tragedy of having to watch a youtube video instead of reading a transcript...
https://news.ycombinator.com/item?id=19023232
LWN does a reasonably faithful summary.
LWN does a reasonably faithful summary.
Previously:
LWN article:
https://news.ycombinator.com/item?id=19023232 (1/29/2019)
This talk:
https://news.ycombinator.com/item?id=19157293 (2/13/2019)
Another youtube version of it:
https://news.ycombinator.com/item?id=17778202 (8/16/2018)
LWN article:
https://news.ycombinator.com/item?id=19023232 (1/29/2019)
This talk:
https://news.ycombinator.com/item?id=19157293 (2/13/2019)
Another youtube version of it:
https://news.ycombinator.com/item?id=17778202 (8/16/2018)
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?
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?
To echo the sibling, but with some more detail:
I worked on a system that (among other things) packaged up a Linux system as a network appliance. The device ran multiple daemons. I have built similar things before in a SysV world, and systemd made the following things easy:
* Starting each daemon only when the system resources it needed (e.g. network up) were ready
* Starting the daemons in the right order relative to each other
* Putting daemon log output in syslog
* Restarting when crashed (for those where it was appropriate)
These all required only a few lines of systemd config, and no special coding in the application. For instance, logging was just printing to stdout/stderr and systemd took care of the rest.
I worked on a system that (among other things) packaged up a Linux system as a network appliance. The device ran multiple daemons. I have built similar things before in a SysV world, and systemd made the following things easy:
* Starting each daemon only when the system resources it needed (e.g. network up) were ready
* Starting the daemons in the right order relative to each other
* Putting daemon log output in syslog
* Restarting when crashed (for those where it was appropriate)
These all required only a few lines of systemd config, and no special coding in the application. For instance, logging was just printing to stdout/stderr and systemd took care of the rest.
If you want to container your services better, then systemd is a good choice; it has plenty of isolation options to secure yourself against misbehaving code. By default systemd will not leave any orphans lying around in your system if the service dies unexpectedly.
You can also manage much more complex dependency situations (like two services being dependent on each other and requiring a restart of both if one crashes).
Systemd Timers are also much more robust and predictable than piling scripts on top of cron, I use them extensively for managing backups on both servers and desktops with automatic reporting for failures.
You can also manage much more complex dependency situations (like two services being dependent on each other and requiring a restart of both if one crashes).
Systemd Timers are also much more robust and predictable than piling scripts on top of cron, I use them extensively for managing backups on both servers and desktops with automatic reporting for failures.
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.
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/ (https://news.ycombinator.com/item?id=8488235)
* https://blog.darknedgy.net/technology/2015/09/05/0/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
... 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
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ (https://news.ycombinator.com/item?id=8488235)
* https://blog.darknedgy.net/technology/2015/09/05/0/
* http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...
... 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
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.
>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.
"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.
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.
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).
System V init wasn't an ancient straw man for Debian users. It was the init system that systemd replaced.
System V init wasn't an ancient straw man for Debian users. It was the init system that systemd replaced.
> I can't really see any other interpretation of their comment.
Then you are unable to distinguish singulars from plurals.
Then you are unable to distinguish singulars from plurals.
No, the comment asks whether it's better than any number of other init systems. In other words, whether there are any other init systems that it's better than. So a counterexample could be a single init system. I see no other sensible interpretation of the sentence. Could you paraphrase what you take it to mean?
Systemd is great if you/the company are developing your own software that need to be daemonized. Its easy to write/copy one .service file for all the distributions than to create some shell scripts/service descriptiors for a bunch of different distros.
The alternative approach is to use supervisord - it also have service descriptors and does what systemd does. The last time we tried to use it(rhed6 had no systemd) we found it lacking some options important to us.
The alternative approach is to use supervisord - it also have service descriptors and does what systemd does. The last time we tried to use it(rhed6 had no systemd) we found it lacking some options important to us.
> The fact that I still have yet to see any such examples in the last half a decade seems pretty telling.
Yes, it's telling; it suggests you've had your fingers deliberately in your ears for five years.
Yes, it's telling; it suggests you've had your fingers deliberately in your ears for five years.
I would like to ask the question the other way around. Now I've been using systemd for a while and gotten used to it I can't image wanting to replace systemd with a collection of scripts.
Maybe systemd is not objectively better or worse. But I'm at least glad there is a standard among Linux systems so I only have to learn the quirks of one init system.
Maybe systemd is not objectively better or worse. But I'm at least glad there is a standard among Linux systems so I only have to learn the quirks of one init system.
It's much easier to manage an application's life-cycle in a systemd unit file than it is in sysvinit bash script.
Unit files are much more declarative and self-contained compared to a bash script. And the bonus is that if you need/still want to use bash, you can do so in systemd.
Unit files are much more declarative and self-contained compared to a bash script. And the bonus is that if you need/still want to use bash, you can do so in systemd.
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.
Something that annoyed me 10 minutes ago
Old fashioned way, when I restart apache having made a typo:
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.
[....] 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!
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.
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)
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.
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.
Systemd is pretty good at hiding error messages. Even if you run the commands it claims will show you error message it makes stupid assumption that your window is infinitely wide or that you want lines truncated instead of wrapped. Even with an infinitely wide window you still don't get nearly as much debugging info as previous systems. For anything complex I end up reverse engineering the startup script and running it from the command line. Then if I update the service systemd notices the file changed, but instead of loading it it runs the old version and complains.
It really seems rather sysadmin hostile and replaces tried and true daemons like ISC's named or unbound with a rather poor systemd replacement.
It really seems rather sysadmin hostile and replaces tried and true daemons like ISC's named or unbound with a rather poor systemd replacement.
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.
Of course if you run sudo systemctl restart apache2.service You get no visual indication it's worked
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.
sudo systemctl restart apache2.service || systemctl status apache2.service
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.
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.
> 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.
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.
> 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.
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.
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.
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.
I mean, I still think it's just a matter of being different. What systemd does is actually more consistent with the old Unix philosophy (in this case at least, systemd is hardly a paragon of Unixy-ness), where a command succeeding without a problem should just return silently. If it fails, you get a short message that says why and reminds you how to check the logs.
I agree that it should just output the log messages, but I don't think there is any serious UI problem here apart from just being different. It's also worth noting that the detailed error message you get from Apache isn't universal and depends on the app and how the init script is written. Plenty of sysv services just give you a cryptic error message on failure, e.g. when I restart postgres on my FreeBSD server with invalid configuration it just says "failed" and I have to then enter another command to see why.
I agree that it should just output the log messages, but I don't think there is any serious UI problem here apart from just being different. It's also worth noting that the detailed error message you get from Apache isn't universal and depends on the app and how the init script is written. Plenty of sysv services just give you a cryptic error message on failure, e.g. when I restart postgres on my FreeBSD server with invalid configuration it just says "failed" and I have to then enter another command to see why.
A litany of arguments against systemd are listed here: http://without-systemd.org/wiki/index.php/Arguments_against_...
Or other wise called a list of dependable design choice that the author doesn't like and a list of incompatibility with the tools the author used before.
The actual speaker is great, but the vast majority of people who have a problem with systemd get there philosophically.
In a "I never actually had to write any code which had significant interaction with existing solutions (openrc, upstart, sysv, bsd, whatever), but I know they exist, so I'll talk about them like they solve the same problems as systemd" way. Which they do not. Want socket activation, double forking, namespaced children, sane scripts/unit files that can build a good dependency tree? You have one option.
Additionally, people see other tools like systemd-network and say "but systemd is doing everything!" Which it isn't. Almost no distros package those as part of the default.
Even if they did, many of the anti-systemd crowd would rather live with a different, slower system (NetworkManager, for example) which is vastly most complicated than what they need. Ditto for systemd-resolved and local caching dnsmasq.
Systemd is not trying to replace NM or BIND or anything. It's basically saying "it's 2019. If you want to be able to work with a system without knowing the ins and outs of 30 different configuration files, and speed up boot time/auditability of your system significantly, you can use these services"
Some things are bad for the community in general. The dependence on dbus (and kdbus), systemd-logind, and other tools aren't very friendly to BSDs to anti-systemd distros. Frankly, from my POV, this isn't systemd's problem. The anti-distros are free to do what they want, knowing the limitations. The BSD guys have written compatibility layers, which you can do, because they're open standards.
Broadly, I'd say that the anti-systemd crowd holds to an idea of "UNIX" purity, as if HP-UX, Tru64, AIX, Solaris, IRIX, and others were uniform. The reality is that they were more different than they were alike, in terms of administrative tools, filesystem layout (is this /sbin/init.d, /etc/rc.d, /sbin/rc.d, etc?) and even software portability. A large reason that GNU autoconf exists is to detect all of the quirks on all of these platforms.
Additionally, anti-systemd people either never used X11R6/OSS/lilo and other old tools, or don't remember how terrible they were. Any large change in the community (X.org fork, ALSA->PulseAudio, grub) draws ire. From the same people who are trying to use syslinux and efibootmgr instead of just using grub2.
Some people would rather debate philosophy than get actual work done, and that's great for open source, even if it's frustrating. But those people never dug into the guts of upstart to make something work, or had 250 lines of sysvinit boilerplate+supervisord saved off somewhere to speed up a process that you can do in 4 lines in a systemd unit file.
In a "I never actually had to write any code which had significant interaction with existing solutions (openrc, upstart, sysv, bsd, whatever), but I know they exist, so I'll talk about them like they solve the same problems as systemd" way. Which they do not. Want socket activation, double forking, namespaced children, sane scripts/unit files that can build a good dependency tree? You have one option.
Additionally, people see other tools like systemd-network and say "but systemd is doing everything!" Which it isn't. Almost no distros package those as part of the default.
Even if they did, many of the anti-systemd crowd would rather live with a different, slower system (NetworkManager, for example) which is vastly most complicated than what they need. Ditto for systemd-resolved and local caching dnsmasq.
Systemd is not trying to replace NM or BIND or anything. It's basically saying "it's 2019. If you want to be able to work with a system without knowing the ins and outs of 30 different configuration files, and speed up boot time/auditability of your system significantly, you can use these services"
Some things are bad for the community in general. The dependence on dbus (and kdbus), systemd-logind, and other tools aren't very friendly to BSDs to anti-systemd distros. Frankly, from my POV, this isn't systemd's problem. The anti-distros are free to do what they want, knowing the limitations. The BSD guys have written compatibility layers, which you can do, because they're open standards.
Broadly, I'd say that the anti-systemd crowd holds to an idea of "UNIX" purity, as if HP-UX, Tru64, AIX, Solaris, IRIX, and others were uniform. The reality is that they were more different than they were alike, in terms of administrative tools, filesystem layout (is this /sbin/init.d, /etc/rc.d, /sbin/rc.d, etc?) and even software portability. A large reason that GNU autoconf exists is to detect all of the quirks on all of these platforms.
Additionally, anti-systemd people either never used X11R6/OSS/lilo and other old tools, or don't remember how terrible they were. Any large change in the community (X.org fork, ALSA->PulseAudio, grub) draws ire. From the same people who are trying to use syslinux and efibootmgr instead of just using grub2.
Some people would rather debate philosophy than get actual work done, and that's great for open source, even if it's frustrating. But those people never dug into the guts of upstart to make something work, or had 250 lines of sysvinit boilerplate+supervisord saved off somewhere to speed up a process that you can do in 4 lines in a systemd unit file.
Solaris and other Unix had things like systemd already.
SMF wasn't added until later in Solaris 10. Other unixes (Tru64, HP-UX, Ultrix, AIX, IRIX, etc) did not have anything like it. They were either BSD init or sysvinit
Rubbish. AIX had the SRC doing service management since 1992. And the SAF, also in Solaris, had been doing management of several classes of services since 1988.
* http://jdebp.eu./FGA/inittab-getty-is-history.html
* http://jdebp.eu./FGA/run-levels-are-history.html
* http://jdebp.eu./FGA/unix-service-access-facility.html
* http://jdebp.eu./FGA/inittab-getty-is-history.html
* http://jdebp.eu./FGA/run-levels-are-history.html
* http://jdebp.eu./FGA/unix-service-access-facility.html
This is _exactly_ what I'm talking about. Neither SAF or srcmstr are equivalent to systemd, and you know it. Making the argument that they're even in the same ballpark is fatuous, except insofar as they have some abstract concept of service groups and replacing sysvinit with something better.
JdeBP(1)
busctl looks simply like mdbus made 10 years later
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.
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.
You are wrong. Read https://news.ycombinator.com/item?id=14735100 .
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.
> 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.
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
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.
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.
> 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/
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...)
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/
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...)
> 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.
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.
> death threats are ridiculous
Fixed that for you...
Fixed that for you...
isostatic(1)
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.
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.
There is runit, used in void. And OpenRC in Funtoo/Gentoo. And the systems used in alternative Operating Systems, Solaris just got mentioned.
There are a bunch of better alternatives out there.
There are a bunch of better alternatives out there.
I believe in the talk he goes into why this (in his opinion) isn’t the case.
I don't think so? I skipped only the questions, maybe there? I didn't hear him mention those other systems, might have missed that.
You can argue that he does that indirectly: He likes that systemd provides something like a service layer, which the tools I mentioned don't really do. Maybe you mean that. That would work, I just happen to think he is wrong there. That's not the job of init, making it a plus point of an init system is some kind of mental gymnastics I don't agree with (though I liked that talk).
You can argue that he does that indirectly: He likes that systemd provides something like a service layer, which the tools I mentioned don't really do. Maybe you mean that. That would work, I just happen to think he is wrong there. That's not the job of init, making it a plus point of an init system is some kind of mental gymnastics I don't agree with (though I liked that talk).
What modern environments?
The problem with systemd is that it's replaced systems that met peoples needs with a single system that many people consider to be worse.
Perhaps there are some niche environments that systemd is needed, and that's great -- but why break things for everyone else?
The problem with systemd is that it's replaced systems that met peoples needs with a single system that many people consider to be worse.
Perhaps there are some niche environments that systemd is needed, and that's great -- but why break things for everyone else?
To flip this around, if you replaced systemd with the old rc init in e.g. Fedora today, you could make the exact same argument:
> The problem with [old init] is that it's replaced systems that met people's needs [systemd] with a single system [old init] that many people consider to be worse. > > Perhaps there are some niche environments that [old init] is needed, and that's great -- but why break things for everyone else?
So the argument is kind of meaningless without a tie-breaker of some kind; perhaps popularity vote.
I think you're under the impression that your views of systemd's relative suitability are held by the majority of users, but I believe that is incorrect.
> The problem with [old init] is that it's replaced systems that met people's needs [systemd] with a single system [old init] that many people consider to be worse. > > Perhaps there are some niche environments that [old init] is needed, and that's great -- but why break things for everyone else?
So the argument is kind of meaningless without a tie-breaker of some kind; perhaps popularity vote.
I think you're under the impression that your views of systemd's relative suitability are held by the majority of users, but I believe that is incorrect.
Change is something many people are naturally averse to, so to change something there should be a good reason for it.
If you sell something and people choose to use it to solve a problem, that's great. If you force change on someone, and not only not deliver any benefit to them, but actually make things worse, expect pushback.
Remember too that most people's systemd impact wasn't just replacing init, it was a whole raft of changes from log formats to dns.
Imagine you had a working systemd setup and someone came along and replaced everything. They claim that there are use cases it's better for, but you don't see yourself with those use cases. You would be averse to that change. You then find out that pretty much every distribution going has got rid of systemd. I suspect you wouldn't be happy.
If you sell something and people choose to use it to solve a problem, that's great. If you force change on someone, and not only not deliver any benefit to them, but actually make things worse, expect pushback.
Remember too that most people's systemd impact wasn't just replacing init, it was a whole raft of changes from log formats to dns.
Imagine you had a working systemd setup and someone came along and replaced everything. They claim that there are use cases it's better for, but you don't see yourself with those use cases. You would be averse to that change. You then find out that pretty much every distribution going has got rid of systemd. I suspect you wouldn't be happy.