Diferencia entre systemctl y comandos de servicio

systemdnos proporciona el systemctlconjunto de comandos que se usa principalmente para permitir que los servicios se inicien en el momento del arranque. También podemos iniciar, detener, recargar, reiniciar y verificar el estado de los servicios con la ayuda de systemctl.

Podemos hacer, por ejemplo sudo systemctl enable service_name, y service_namese iniciará automáticamente en el momento del arranque. También podemos desactivar los servicios para que no se inicien en el momento del arranque.

¿Es la única diferencia entre los comandos servicey systemctlque systemctlse pueden usar para habilitar el inicio de los servicios en tiempo de ejecución? ¿Podemos usar systemctlen cualquier servicio? ¿Qué otras diferencias significativas hay?

El servicecomando es un script de envoltura que permite a los administradores del sistema iniciar, detener y verificar el estado de los servicios sin preocuparse demasiado por el sistema de inicio real que se está utilizando. Antes de la introducción de systemd, era un contenedor de /etc/init.dsecuencias de comandos y de Upstart initctlcomando, y ahora es un contenedor para estos dos y systemctl así.

¡Usa la fuente, Luke!

Comprueba el 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

Si eso no funciona, busca 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

Y si eso también falla, recurre a los /etc/init.dscripts del Sistema V :

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

Dado que el servicecomando es un contenedor bastante simple, solo admite un subconjunto limitado de acciones en comparación con lo que podría proporcionar el sistema de inicio real.

Para la portabilidad sobre varias versiones de Ubuntu, los usuarios pueden usar de manera confiable el servicecomando para iniciar, detener, reiniciar o examinar el estado de un servicio. Para las tareas más complejas, sin embargo, el comando real que se utiliza, ya sea que initctlo systemctlo la /etc/init.dsecuencia de comandos podría tener que ser utilizado directamente.

Además, al ser un contenedor, el servicescript en algunos casos también hace más de lo que podría hacer el comando equivalente directo. Por ejemplo:

• Siempre ejecuta /etc/init.dscripts en un entorno limpio. (Tenga en cuenta la invocación larga de env comandos en la run_via_sysvinitfunción anterior).
• Se asigna restarten los sistemas Upstart a una combinación de stop/ start, ya que se initctl restartgenerará un error si el servicio no se está ejecutando.

• Detiene los sockets cuando detiene los servicios systemd que tienen sockets asociados:

  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.

Los servicios de inicio se habilitaron directamente en el archivo de configuración del servicio (o se deshabilitaron mediante anulaciones), y los scripts del Sistema V se habilitaron o deshabilitaron con el update-rc.dcomando (que administraba enlaces simbólicos en los /etc/rc*directorios), por lo que el servicecomando nunca estuvo involucrado en habilitar o deshabilitar los servicios en el arranque .

• systemd es compatible con versiones anteriores de SysV.
• carga servicios paralelos al inicio
• proporciona activación a pedido de un servicio
• se basa en la dependencia
• y mucho más, supongo ...

Hay mucho más de lo que mencionaste que systemctles capaz de hacer.

systemd funciona con unidades, hay diferentes tipos de unidades: objetivos, servicios, sockets, etc. los objetivos son el mismo concepto que los niveles de ejecución, son un montón de unidades juntas.

Puede usar systemctlpara establecer u obtener el objetivo predeterminado del sistema.

systemctl get-default

Puedes ir a otros objetivos:

systemctl isolate multiuser.target

Otros objetivos son: multiusuario, gráfico, recue, emergencia, reinicio, apagado.

Como dijiste, puedes usar systemctlpara administrar servicios, algunos de los otros comandos relacionados con la administración de servicios que conozco son:

# 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

Puede usarlo para conocer el estado de un servicio:

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

Puede enmascarar o desenmascarar un servicio:

systemctl mask name.service
systemctl unmask name.service

Cuando oculta un servicio al que estará vinculado /dev/null, de manera manual o automática, otros servicios no pueden activarlo / habilitarlo. (deberías desenmascararlo primero).

Otro uso de systemctl es enumerar unidades:

systemctl list-units

Que enumera todo tipo de unidades, cargadas y activas.

Lista de unidades de servicio:

systemctl list-units --type=service

O para enumerar todas las unidades disponibles, no solo las cargadas y activadas:

systemctl list-unit-files

Puede crear alias o incluso controlar máquinas remotas

systemctl --host [email protected] list-units

Por otro lado, servicehace lo que tiene que hacer, administrar servicios y no tener nada que ver con los negocios de otras personas;)