systemd gives us the systemctl commands suite which is mostly used to enable services to start at boot time. We can also start, stop, reload, restart and check status of services with the help of systemctl.

We can do, for example, sudo systemctl enable service_name, and service_name will automatically start at boot time. We can also disable services not to start at boot time.

Is the only difference between the service and systemctl commands that systemctl can be used to enable the start of services at run time? Can we use systemctl on any service? What other significant differences are there?

  • I think you picked the wrong answer, myself. Dec 17, 2017 at 4:58

2 Answers 2


The service command is a wrapper script that allows system administrators to start, stop, and check the status of services without worrying too much about the actual init system being used. Prior to systemd's introduction, it was a wrapper for /etc/init.d scripts and Upstart's initctl command, and now it is a wrapper for these two and systemctl as well.

Use the source, Luke!

It checks for Upstart:

# Operate against system upstart, not session
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \
   && initctl version 2>/dev/null | grep -q upstart \
   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
   # Upstart configuration exists for this job and we're running on upstart

If that doesn't work, it looks for systemd:

if [ -d /run/systemd/system ]; then


# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]

And if that fails as well, it falls back to System V /etc/init.d scripts:

run_via_sysvinit() {
   # Otherwise, use the traditional sysvinit
   if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
      echo "${SERVICE}: unrecognized service" >&2
      exit 1


Since the service command is a fairly simple wrapper, it only supports a limited subset of actions compared to what the actual init system might provide.

For portability over various versions of Ubuntu, users can reliably use the service command to start, stop, restart or examine the status of a service. For more complex tasks, however, the actual command being used, be that initctl or systemctl or the /etc/init.d script might have to be used directly.

Further, being a wrapper, the service script in some cases also does more than the direct equivalent command might do. For example:

  • It always executes /etc/init.d scripts in a clean environment. (Note the long env command invocation in the run_via_sysvinit function above.)
  • It maps restart on Upstart systems to a combination of stop/start, since a plain initctl restart will error out if the service isn't running already.
  • It stops sockets when stopping systemd services which have associated sockets:

    case "${ACTION}" in
         exec systemctl $sctl_args ${ACTION} ${UNIT}
         # Follow the principle of least surprise for SysV people:
         # When running "service foo stop" and foo happens to be a service that
         # has one or more .socket files, we also stop the .socket units.
         # Users who need more control will use systemctl directly.

Upstart services were enabled directly in the service configuration file (or disabled via overrides), and System V scripts were enabled or disabled with the update-rc.d command (which managed symlinks in the /etc/rc* directories), so the service command was never involved in enabling or disabling services on boot.

  • 1
    Strange, service --status-all does not show a service that I installed using systemctl...
    – jjxtra
    Sep 14, 2020 at 15:25

There are a lot more than what you mentioned that systemctl is capable of:

  • systemd is backwards compatible with SysV.
  • loads services parallel at startup
  • it's provides on-demand activation of a service
  • it's dependency based
  • and a lot more I guess...

systemd works with units, there are different type of units: targets, services, sockets, etc. targets are same concept as runlevels, they are a bunch of units together.

You can use systemctl to set or get the default system target.

systemctl get-default

You can go into other targets:

systemctl isolate multiuser.target

Other targets are: multiuser, graphical, recue, emergency, reboot, poweroff.

As you said, you can use systemctl to manage services, some of the other commands related to service management which I'm aware of are:

# Restarts a service only if it is running.
systemctl try-restart name.service

# Reloads configuration if it's possible.
systemctl reload name.service

# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service

You can use it to find out about a service status:

systemctl status name.service

systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load

You can mask or unmask a service:

systemctl mask name.service
systemctl unmask name.service

Wen you mask a service it will be linked to /dev/null, so manually or automatically other services can't active/enable it. (you should unmask it first).

Another usage of systemctl is to list units:

systemctl list-units

Which list all kind of units, loaded and active.

List service units:

systemctl list-units --type=service

Or to list all available units not just loaded and activated ones:

systemctl list-unit-files

You can create aliases or even control remote machines

systemctl --host [email protected] list-units

At the other hand service does what it have to do, managing services and having nothing to do with other peoples business ;)

  • 3
    that was a perfect answer, Is there anything which service can do but not systemctl ?
    – luv.preet
    Apr 10, 2017 at 23:10
  • 1
    Nothing that I'm aware of that, I think having a look at service man page would be helpful.
    – Ravexina
    Apr 10, 2017 at 23:12
  • 2
    There's couple obvious differences. Syntax is one. Another is that systemv scripts never dealt with sockets, as far as i know. The fact that systemd is trying to deal with network type of stuff is another, and it's a frequent point of critique. Over all, systemd is trying to do more than just starting services Apr 11, 2017 at 1:28
  • 1
    I would like to make a complaint here about systemd hiding log messages from failed service start attempts. Pre-systemd, service start would let me see right away why my service wouldn't start. Post-systemd, I have to look at four or five different logs before I can find it. All that said, my comment is undoubtedly off topic and will probably be deleted. Apr 11, 2017 at 2:23
  • 18
    AFAICS This answer doesn't seem to tell anything about the service command, wasn't that part of the question?
    – ilkkachu
    Apr 11, 2017 at 8:04

You must log in to answer this question.

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