6 ms·

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

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.

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.