10

I just installed CentOS 7.1 on one server and I'm confused by how systemctl works compared to service.

On CentOS 6, I would get feedback when running service, such as:

root@centos6 [~]# service mysql restart
Shutting down MySQL........................................[  OK  ]
Starting MySQL.............................................[  OK  ]

root@centos6 [~]# service mysql status
MySQL running (910285)                                     [  OK  ]
root@centos6 [~]#

However on CentOS 7, when I use systemctl, I get nothing. I don't know what happened, or if something even happened:

root@centos7 [~]# systemctl restart mysql
root@centos7 [~]# /bin/systemctl restart  mysql.service

# Nothing happened

And when I run service on CentOS 7, this happens:

root@centos7 [~]# service mysql restart
Redirecting to /bin/systemctl restart  mysql.service

What am I'm missing?

munich
  • 276
  • 1
  • 2
  • 7
  • I guess your question is NOT what you are "missing". I think your question is how to get a verbose output of `systemctl restart`. :-) – reichhart Aug 02 '22 at 11:30

4 Answers4

14

Here is what I do:

systemctl start my-service && journalctl -fexu my-service

journalctl is the simplest way to get output from your systemd services.

  • -f follows the log output of my-service until I quit (ctrl-C).
  • -e scrolls to the end (most recent) log messages.
  • -x explanations from the Journal Message Catalog, if available.
    (See also https://www.freedesktop.org/wiki/Software/systemd/catalog/)
  • -u will only show logs from the my-service unit.
rutger
  • 249
  • 2
  • 3
  • 1
    This provides feedback from actions long gone as well, sadly. It's also too verbose, repeating things it really should not (because of a central log I guess). Thanks for it, nonetheless; it's a small patch for some sorely missing functionality. – Steve Horvath Jan 22 '21 at 06:29
  • 2
    This is a pretty ugly hack, needing 2 commands for doing one command's job. Systemctl is broken by not providing a verbose flag (even several levels of verbosity for debugging) Every other Linux command on the planet supports this and for good reason. The zero feedback policy of Unix is outdated by this day, we live in a communicative age, we like feedback when something succeeds (use the quiet flag for no output), imagine the kernel messages on startup not being displayed because "nothing failed", pretty stupid right? It's super easy to implement really. Need a good example? Look at ansible! – Markus Bawidamann Feb 06 '21 at 04:58
  • Yes, even if you filter restart debug output with e.g. `grep` you actually need two commands. – reichhart Aug 02 '22 at 11:31
  • @MarkusBawidamann do you have a link to this "zero feedback policy of Unix"? – Jürgen A. Erhard Mar 17 '23 at 11:41
  • @JürgenA.Erhard Of course: https://clig.dev/ quote from link: Display output on success, but keep it brief. Traditionally, when nothing is wrong, UNIX commands display no output to the user. This makes sense when they’re being used in scripts, but can make commands appear to be hanging or broken when used by humans. For example, cp will not print anything, even if it takes a long time. – Markus Bawidamann Mar 20 '23 at 13:13
5

Like any good unix command, systemctl outputs nothing unless there was a problem, or you ran a command that explicitly requires output. If you see nothing, then the command was successful.

If you wish, you can run systemctl status mysql to see its current status.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • 7
    BS. "good" commands actually execute. `systemctl start` appears to be a noop on my osmc system. And its not as if I'm a systemd newbie. I've been running it on Ubuntu, Debian and Raspbian for over a year. And in my particular case `systemctl status deluged` is showing the results from two hours ago, rather than my last 3 or 4 invocations. – Auspex Jun 12 '16 at 20:11
  • Good or not, this is by design. systemd start/stop/restart commands won't show anything after successful invocation. You can either check the return code with `$?`, or use `systemctl status servicename` to make sure it did what you wanted. There is unfortunately no "verbose" option to help you with this (the `-o verbose` option only works with the status command). – James Sneeringer Nov 07 '16 at 18:15
  • 1
    @Auspex You appear to have an issue unrelated to this question. You should ask a new question. – Michael Hampton Mar 09 '18 at 16:59
  • 6
    What a nonsense bit of doctrine. Would you like me to list the good UNIX commands that output something even when there is no problem? Would you like me to tell you how many of those commands were originally authored by the people who invented UNIX? – ruief Mar 10 '18 at 00:00
  • 1
    @MichaelHampton wtf? I _don't_ have an issue at all. I had a comment on your ridiculous post. "Good" commands always do something, and _always_ tell you what they did. I commented on the behaviour on my OSMC system purely because that was the most egregious example of poor behaviour on the part of `systemctl start` – Auspex Mar 10 '18 at 22:02
  • 4
    What "good unix command" doesn't provide debugging options? A systemd unit file can be quite complex, so "start" or "stop" could translate into a dozen different actions. Then there's the perennial question of "is it hanging or is it just busy?" Even cp, mv, rm, and ln have a verbose option and you can't get much simpler than those. – kbolino Apr 18 '18 at 17:41
  • Despite the fact `systemctl` definitly should have a verbose option, I must disagree with the *Like any good unix command ...* part. Yes, some don't display anything when its a success, but there are not necessarily **better** than others. – 4wk_ May 07 '18 at 16:25
  • 1
    Yes, and any good unix command therefore has a verbose option, where it reports what it is actually doing. Where is it in systemctl??? But in truth, not reporting anything is not smart: Think about all the tools that report successful competion and where it is really important that they do. If you go with that logic, apt install vlc would report absolutely nothing, you would know what it did. This "unix philosophy" is obsolete in the 21st century where USERFRIENDLY no longer just optional. – Markus Bawidamann Feb 05 '21 at 14:39
  • Good point on the debugging option, EVERY command needs that. and Verbose does exactly that. Even more important, -vvv to increase the level. – Markus Bawidamann Feb 05 '21 at 14:43
  • 1
    Is this really an answer or a comment? – reichhart Aug 02 '22 at 11:26
1

My "solution" to this (did a long time ago) was to write a miniscript that basically does what's suggested in one of the answers above: systemctl restart myservice and right after that systemctl status myservice, so you just run a restart and get the status afterwards. I also agree that this is an unnecessary solution as systemctl should already have a verbose/status option implemented but it is what it is.

Gustavo
  • 11
  • 1
1

Unfortunately systemctl does not provide a "verbose" option like most Unix commands do.

One solution is to increase SYSTEMD_LOG_LEVEL to debug (info is useless here) and then filter the output like e.g.:

$ SERVICES="smartmontools cron xxxxx"
$ SYSTEMD_LOG_LEVEL=debug systemctl restart $SERVICES 2>&1|egrep "Got result .* for job|Failed"
Failed to restart xxxxx.service: Unit xxxxx.service not found.
Got result done/Success for job cron.service
Got result done/Success for job smartmontools.service

You can also add a prefix like e.g.

$ SYSTEMD_LOG_LEVEL=debug systemctl restart $SERVICES 2>&1|egrep -i "Got result .* for job|Failed"|sed 's,^,restart: ,'
restart: Failed to restart xxxxx.service: Unit xxxxx.service not found.
restart: Got result done/Success for job cron.service
restart: Got result done/Success for job smartmontools.service

SYSTEMD_LOG_LEVEL might not be available on all systems.

reichhart
  • 360
  • 2
  • 7