4 ms·

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

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.
  - isostatic 8y ago
    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.
    - lightedman 8y ago
      "Logging it is great, it's the fact the interface says "look in the log" rather than doing it for you." So now I have to go digging instead of being told upfront what the problem is. No thanks. Time is money, and having to dig through a logfile when simply putting the error message after the failure to execute would have sufficed, just wastes time and money. That's why we removed every Linux machine from our production lines at the solar plant I manage, and went back to (ugh) embedded Windows. SystemD is a waste of time and money in every single one of our experiences with it.
gh02t 8y ago
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.

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.
- isostatic 8y ago
  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.
  - lightedman 8y ago
    "Logging it is great, it's the fact the interface says "look in the log" rather than doing it for you." So now I have to go digging instead of being told upfront what the problem is. No thanks. Time is money, and having to dig through a logfile when simply putting the error message after the failure to execute would have sufficed, just wastes time and money. That's why we removed every Linux machine from our production lines at the solar plant I manage, and went back to (ugh) embedded Windows. SystemD is a waste of time and money in every single one of our experiences with it.

gh02t 8y ago

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.