Questão Diferença entre Systemctl e Service


systemd nos dá a systemctl comando que é usado principalmente para permitir que os serviços iniciem no momento da inicialização. Podemos também iniciar, parar, recarregar, reiniciar e verificar o status dos serviços com a ajuda de systemctl.

Nós podemos fazer sudo systemctl enable service_namee o serviço será iniciado 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 o service e systemctl comandos que systemctl pode iniciar serviços em tempo de execução? Podemos usar systemctl em algum serviço? Quais outras diferenças significativas existem?


80
2018-04-10 21:35


origem


Eu acho que você escolheu a resposta errada, eu mesmo. - Evan Carroll


Respostas:


o service O comando é um script 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 em uso. Antes da introdução do systemd, era um invólucro para /etc/init.d scripts e upstart initctl comando, e agora é um wrapper para esses dois e  systemctl também.

Use a fonte, Luke!

Verifica por 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 falhar também, ele volta para o 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

Desde o service O comando é um wrapper bastante simples, ele suporta apenas um subconjunto limitado de ações comparado ao que o sistema init real pode fornecer.

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

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

  • Ele sempre executa /etc/init.d scripts em um ambiente limpo. (Note o longo  env invocação de comando no run_via_sysvinit função acima.)
  • Mapas restart em sistemas Upstart para uma combinação de stop/start, desde uma planície initctl restart irá cometer erros se o serviço ainda não estiver em execução.
  • Para os sockets ao parar os serviços do systemd que possuem sockets 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 do Upstart foram ativados diretamente no arquivo de configuração do serviço (ou desativados por meio de substituições), e os scripts do System V foram ativados ou desativados com o update-rc.d comando (que gerenciava links simbólicos no /etc/rc* diretórios), de modo que service O comando nunca esteve envolvido em ativar ou desativar serviços na inicialização.


73
2018-04-11 03:03



excelente explicação, obrigado. - Willa O Ng'wana


  • O systemd é retrocompatível com o SysV.
  • carrega serviços paralelos na inicialização
  • ele 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 systemctl é capaz de.

systemd funciona com unidades, existem diferentes tipos de unidades: alvos, serviços, sockets, etc. os alvos são o mesmo conceito que runlevels, eles são um conjunto de unidades juntos.

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

systemctl get-default

Você pode entrar em outros alvos:

systemctl isolate multiuser.target

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

Como você disse, você pode usar systemctl Para 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 saber mais sobre o status de um 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, ele será vinculado a /dev/null, manualmente 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 lista 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 carregadas e ativadas:

systemctl list-unit-files

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

systemctl --host ravexina@192.168.56.4 list-units

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


21
2018-04-10 21:53



que foi uma resposta perfeita, existe alguma coisa que service pode fazer, mas não systemctl ? - luv.preet
Nada que eu saiba disso, acho que dar uma olhada página de manual de serviço seria útil. - Ravexina
Há algumas diferenças óbvias. A sintaxe é uma. Outra é que os scripts systemv nunca lidaram com sockets, tanto quanto eu sei. O fato de o systemd estar tentando lidar com o tipo de rede é outra, e é um ponto freqüente de crítica. Acima de tudo, o systemd está tentando fazer mais do que apenas iniciar serviços - Sergiy Kolodyazhnyy
Eu gostaria de fazer uma reclamação aqui sobre systemd escondendo mensagens de log de falha service start tentativas. Pré-systemd, service start me deixaria ver imediatamente porque meu serviço não começaria. Post-systemd, eu tenho que olhar para quatro ou cinco logs diferentes antes que eu possa encontrá-lo. Tudo o que disse, meu comentário é, sem dúvida, fora do tópico e provavelmente será excluído. - Ross Presser
AFAICS Esta resposta parece não dizer nada sobre o service comando, não era essa parte da questão? - ilkkachu