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?


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.
  • 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 at 6:29
  • 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 6 at 4:58

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.

  • 4
    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 7 '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 9 '18 at 16:59
  • 3
    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 0:00
  • 2
    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

Since the emergence of the cloud, humans no longer start and stop services by hand, so this command does not need to provide any feedback, even as an option. Thanks for flying systemd!

  • Say what??? That is wrong on every level conceivable. It assumes (wrongly) that things will never fail, break or get buggy. You need to be able to troubleshoot and that is when you need feedback, positive and negative. In 20+ years of IT I have known problems that can be fixed and ones that are impossible to and the ones that were impossible where pretty ALWAYS due to missing logs or a trail what the tool is doing and WHAT IS GOING WRONG.Verbose is A MUST for all tools. Systemd, in other respect a good tool, looks stupid and broken here! – Markus Bawidamann Feb 6 at 4:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.