Diferença entre systemctl e comandos de serviço

systemdnos fornece o systemctlconjunto de comandos que é usado principalmente para permitir que os serviços iniciem no momento da inicialização. Também podemos iniciar, parar, recarregar, reiniciar e verificar o status dos serviços com a ajuda de systemctl.

Podemos fazer, por exemplo sudo systemctl enable service_name, e service_nameiniciaremos automaticamente no momento da inicialização. Também podemos desativar os serviços para não iniciar no momento da inicialização.

A única diferença entre os comandos servicee systemctlque systemctlpode ser usada para ativar o início dos serviços em tempo de execução? Podemos usar systemctlem qualquer serviço? Que outras diferenças significativas existem?

O servicecomando é um script de wrapper que permite que os administradores do sistema iniciem, parem e verifiquem o status dos serviços sem se preocupar muito com o sistema init real que está sendo usado. Antes da introdução do systemd, foi um wrapper para /etc/init.dscripts e de Upstart initctlcomando, e agora é um wrapper para esses dois e systemctl bem.

Use a fonte, Luke!

Ele verifica o 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

Se isso não funcionar, ele procura pelo 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

E se isso também falhar, ele voltará aos /etc/init.dscripts do System 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

Como o servicecomando é um wrapper bastante simples, ele suporta apenas um subconjunto limitado de ações em comparação com o que o sistema init real pode fornecer.

Para portabilidade em várias versões do Ubuntu, os usuários podem usar com segurança o servicecomando para iniciar, parar, reiniciar ou examinar o status de um serviço. Para tarefas mais complexas, no entanto, o comando real sendo usado, seja esse initctlou systemctlou o /etc/init.dscript pode ter que ser usado diretamente.

Além disso, sendo um invólucro, o servicescript em alguns casos também faz mais do que o comando equivalente direto pode fazer. Por exemplo:

• Ele sempre executa /etc/init.dscripts em um ambiente limpo. (Observe a chamada de comando longa env na run_via_sysvinitfunção acima.)
• Ele mapeia restartnos sistemas Upstart para uma combinação de stop/ start, uma vez que um simples initctl restarterro ocorrerá se o serviço já não estiver em execução.

• Ele interrompe soquetes ao interromper serviços do systemd que possuem soquetes associados:

  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.

Os serviços iniciados foram ativados diretamente no arquivo de configuração do serviço (ou desativados por substituições) e os scripts do System V foram ativados ou desativados com o update-rc.dcomando (que gerenciava links simbólicos nos /etc/rc*diretórios); portanto, o servicecomando nunca esteve envolvido na ativação ou desativação de serviços na inicialização .

• O systemd é compatível com o SysV.
• carrega serviços paralelos na inicialização
• fornece ativação sob demanda de um serviço
• é baseado em dependência
• e muito mais eu acho ...

Há muito mais do que você mencionou que systemctlé capaz.

systemd trabalha com unidades, existem diferentes tipos de unidades: destinos, serviços, soquetes etc. destinos são o mesmo conceito que os níveis de execução, são um conjunto de unidades.

Você pode usar systemctlpara definir ou obter o destino padrão do sistema.

systemctl get-default

Você pode entrar em outros destinos:

systemctl isolate multiuser.target

Outros destinos são: multiusuário, gráfico, recue, emergência, reinicialização, desligamento.

Como você disse, você pode usar systemctlpara gerenciar serviços, alguns dos outros comandos relacionados ao gerenciamento de serviços que eu conheço são:

# 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

Você pode usá-lo para descobrir um status de serviço:

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

Você pode mascarar ou desmascarar um serviço:

systemctl mask name.service
systemctl unmask name.service

Quando você mascara um serviço ao qual ele está vinculado /dev/null, manual ou automaticamente outros serviços não podem ativá-lo / ativá-lo. (você deve desmascará-lo primeiro).

Outro uso do systemctl é listar unidades:

systemctl list-units

Que listam todos os tipos de unidades, carregadas e ativas.

Listar unidades de serviço:

systemctl list-units --type=service

Ou para listar todas as unidades disponíveis, não apenas as carregadas e ativadas:

systemctl list-unit-files

Você pode criar aliases ou até controlar máquinas remotas

systemctl --host ravexina@192.168.56.4 list-units

Por outro lado, servicefaz o que tem que fazer, gerenciando serviços e não tendo nada a ver com os negócios de outras pessoas;)