4 ms·

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

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

by gh02t 8y ago

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