Diferença entre systemctl e comandos de serviço

143

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?

luv.preet
fonte
Eu acho que você escolheu a resposta errada.
Evan Carroll

Respostas:

144

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 .

muru
fonte
34
  • 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 [email protected] 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;)

Ravexina
fonte
11
essa foi uma resposta perfeita: existe algo que servicepode fazer, mas não systemctl?
Luv.preet
Nada do que eu saiba, acho que dar uma olhada na página de manual de serviço seria útil.
Ravexina
11
Existem algumas diferenças óbvias. Sintaxe é uma. Outra é que os scripts systemv nunca lidaram com soquetes, tanto quanto eu sei. O fato de o systemd estar tentando lidar com o tipo de rede é outro, e é um ponto de crítica frequente. Acima de tudo, systemd está tentando fazer mais do que os serviços apenas começando
Sergiy Kolodyazhnyy
Gostaria de fazer uma reclamação aqui sobre o systemd ocultando mensagens de log de service starttentativas falhas . Antes do systemd, service startdeixava-me ver imediatamente por que meu serviço não foi iniciado. Depois do sistema, tenho que olhar para quatro ou cinco logs diferentes antes de poder encontrá-lo. Tudo isso dito, meu comentário é sem dúvida fora de tópico e provavelmente será excluído.
Ross Presser
11
AFAICS Esta resposta parece não dizer nada sobre o servicecomando, não fazia parte da pergunta?
Ilkkachu