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?

  • 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 2, 2022 at 11:30

4 Answers 4


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.
  • 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. Jan 22, 2021 at 6: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! Feb 6, 2021 at 4:58
  • Yes, even if you filter restart debug output with e.g. grep you actually need two commands.
    – reichhart
    Aug 2, 2022 at 11:31
  • @MarkusBawidamann do you have a link to this "zero feedback policy of Unix"? Mar 17, 2023 at 11:41
  • @JürgenA.Erhard Of course: 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. Mar 20, 2023 at 13:13

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.

  • 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, 2016 at 20:11
  • 1
    @Auspex You appear to have an issue unrelated to this question. You should ask a new question. Mar 9, 2018 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, 2018 at 0: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, 2018 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, 2018 at 17:41

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .