Difference between systemctl and service commands

Question

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?

Answer 1

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
unset UPSTART_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
then
   # 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
   is_systemd=1
fi

...

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

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
      exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
   else
      echo "${SERVICE}: unrecognized service" >&2
      exit 1
   fi
}

...
run_via_sysvinit

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
    restart|status)
       exec systemctl $sctl_args ${ACTION} ${UNIT}
    ;;
    start|stop)
       # 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.

Answer 2

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 ravexina@192.168.56.4 list-units

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