Diferença entre Systemctl e Service

Question

systemd nos fornece o comando systemctl , que é usado principalmente para permitir que os serviços sejam iniciados 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 sudo systemctl enable service_name e 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 os comandos service e systemctl em que systemctl pode iniciar serviços em tempo de execução? Podemos usar systemctl em qualquer serviço? Quais outras diferenças significativas existem?

    

Answer 1

O comando service é um script wrapper que permite que os administradores do sistema iniciem, interrompam 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 wrapper para /etc/init.d scripts e o comando initctl do Upstart, e agora é um wrapper para esses dois e systemctl também.

Use a fonte, Luke!

Verifica para 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, procure por 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, ele volta para os scripts do System V /etc/init.d :

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 comando service é um wrapper bastante simples, ele suporta apenas um subconjunto limitado de ações comparado ao 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 comando service para iniciar, parar, reiniciar ou examinar o status de um serviço. Para tarefas mais complexas, no entanto, o comando real sendo usado, seja que initctl ou systemctl ou o script /etc/init.d possa ter que ser usado diretamente.

Além disso, por ser um wrapper, o script service 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. (Observe a invocação do comando long env na função run_via_sysvinit acima.)
• Ele mapeia restart em sistemas Upstart para uma combinação de stop / start , já que um initctl restart simples terá erro 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 comando update-rc.d (que gerenciava links simbólicos nos diretórios /etc/rc* ), portanto o service command nunca esteve envolvido em ativar ou desativar serviços na inicialização.

    

Answer 2

O
• systemd é compatível com versões anteriores do 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 de fazer.

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 systemctl para definir ou obter o destino do sistema padrão.

systemctl get-default

Você pode entrar em outros destinos:

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ê mascarar um serviço, ele será vinculado a /dev/null , portanto, manualmente ou automaticamente, outros serviços não poderão 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 [email protected] 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;)