6 ms·

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 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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 8y ago
        > 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.
seba_dos1 8y ago
busctl looks simply like mdbus made 10 years later
npongratz 8y ago
A litany of arguments against systemd are listed here: http://without-systemd.org/wiki/index.php/Arguments_against_systemd http://without-systemd.org/wiki/index.php/Arguments_against_...
- nickik 8y ago
  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.
evol262 8y ago
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.
- nickik 8y ago

isostatic 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        > 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.

seba_dos1 8y ago

busctl looks simply like mdbus made 10 years later

npongratz 8y ago

A litany of arguments against systemd are listed here: http://without-systemd.org/wiki/index.php/Arguments_against_systemd http://without-systemd.org/wiki/index.php/Arguments_against_...

nickik 8y ago
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.

evol262 8y ago

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.

nickik 8y ago