Service Management em Systemd

Mostra os comandos systemctl start e systemctl stop e explica como as alterações de estado persistem.

Para iniciar um serviço, use o comando systemctl start:

sudo systemctl start sshd

Para interromper um serviço, use o comando systemctl stop:

sudo systemctl stop sshd

A alteração do estado de um serviço só dura enquanto o sistema permanece no mesmo estado.

Se você interromper um serviço e, em seguida, alterar o destino de estado do sistema para um em que o serviço esteja configurado para ser executado (por exemplo, reinicializando o sistema), o serviço será reiniciado. Da mesma forma, iniciar um serviço não permite que o serviço seja iniciado após uma reinicialização. Consulte Ativando e Desativando Serviços.

Explica como ativar, desativar, mascarar e desmascarar serviços para que eles sejam iniciados (ou permaneçam parados) nas reinicializações.

Você pode usar o comando systemctl para ativar ou desativar um serviço do início quando o sistema for inicializado, por exemplo:

sudo systemctl enable httpd

Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

O comando enable ativa um serviço criando um link simbólico para o destino de estado do sistema de nível mais baixo no qual o serviço é iniciado. No exemplo anterior, o comando cria o link simbólico httpd.service para o destino multi-user.

A desativação de um serviço remove o link simbólico:

sudo systemctl disable httpd

Removed /etc/systemd/system/multi-user.target.wants/httpd.service.

Para verificar se um serviço está ativado, use o subcomando is-enabled, conforme mostrado nos seguintes exemplos:

systemctl is-enabled httpd

disabled

systemctl is-enabled sshd

enabled

Depois de executar o comando systemctl disable, o serviço ainda pode ser iniciado ou interrompido por contas de usuário, scripts e outros processos.

No entanto, se você precisar garantir que o serviço não possa ser iniciado inadvertidamente, por exemplo, por um serviço em conflito, use o comando systemctl mask da seguinte forma:

sudo systemctl mask httpd

Created symlink from '/etc/systemd/system/multi-user.target.wants/httpd.service' to '/dev/null'

O comando mask define a referência de serviço como /dev/null. Se você tentar iniciar um serviço que foi mascarado, receberá um erro conforme mostrado no seguinte exemplo:

sudo systemctl start httpd

Failed to start httpd.service: Unit is masked.

Para revincular a referência de serviço de volta ao arquivo de configuração da unidade de serviço correspondente, use o comando systemctl unmask:

sudo systemctl unmask httpd

Para obter mais informações, consulte a página do manual systemctl(1).

Detalha os comandos systemctl is-active e status para verificar a integridade do serviço e os grupos de controle.

Para verificar se um serviço está em execução, use o subcomando is-active. A saída seria ativa ou inativa, conforme mostrado nos seguintes exemplos:

systemctl is-active httpd

active

systemctl is-active sshd

inactive

O subcomando status fornece um resumo detalhado do status de um serviço, incluindo uma árvore que exibe as tarefas no grupo de controle (CGroup) que o serviço implementa:

systemctl status httpd

httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since ...
     Docs: man:httpd.service(8)
 Main PID: 11832 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 26213)
   Memory: 32.5M
   CGroup: /system.slice/httpd.service
           ├─11832 /usr/sbin/httpd -DFOREGROUND
           ├─11833 /usr/sbin/httpd -DFOREGROUND
           ├─11834 /usr/sbin/httpd -DFOREGROUND
           ├─11835 /usr/sbin/httpd -DFOREGROUND
           └─11836 /usr/sbin/httpd -DFOREGROUND

Jul 17 00:14:32 Unknown systemd[1]: Starting The Apache HTTP Server...
Jul 17 00:14:32 Unknown httpd[11832]: Server configured, listening on: port 80
Jul 17 00:14:32 Unknown systemd[1]: Started The Apache HTTP Server.

cgroup é um conjunto de processos que são vinculados para que você possa controlar seu acesso aos recursos do sistema. No exemplo, o cgroup para o serviço httpd é httpd.service, que está no segmento system.

As fatias dividem o cgroups em um sistema em categorias diferentes. Para exibir a hierarquia de segmentos e cgroup, utilize o comando systemd-cgls:

systemd-cgls

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ └─init.scope
│   │   ├─6488 /usr/lib/systemd/systemd --user
│   │   └─6492 (sd-pam)
│   └─session-7.scope
│     ├─6484 sshd: root [priv]
│     ├─6498 sshd: root@pts/0
│     ├─6499 -bash
│     ├─6524 sudo systemd-cgls
│     ├─6526 systemd-cgls
│     └─6527 less
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 16
└─system.slice
  ├─rngd.service
  │ └─1266 /sbin/rngd -f --fill-watermark=0
  ├─irqbalance.service
  │ └─1247 /usr/sbin/irqbalance --foreground
  ├─libstoragemgmt.service
  │ └─1201 /usr/bin/lsmd -d
  ├─systemd-udevd.service
  │ └─1060 /usr/lib/systemd/systemd-udevd
  ├─polkit.service
  │ └─1241 /usr/lib/polkit-1/polkitd --no-debug
  ├─chronyd.service
  │ └─1249 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─1152 /sbin/auditd
  │ └─1154 /usr/sbin/sedispatch
  ├─tuned.service
  │ └─1382 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
  ├─systemd-journald.service
  │ └─1027 /usr/lib/systemd/systemd-journald
  ├─atd.service
  │ └─1812 /usr/sbin/atd -f
  ├─sshd.service
  │ └─1781 /usr/sbin/sshd

O system.slice contém serviços e outros processos do sistema. O user.slice contém processos do usuário, que são executados em cgroups transitórios chamados escopos.

No exemplo, os processos para o usuário com o ID 1000 estão em execução no escopo session-7.scope no segmento /user.slice/user-1000.slice.

Você pode usar o comando systemctl para limitar a CPU, Entrada/Saída, memória e outros recursos disponíveis para os processos em grupos de serviço e escopo. Consulte Controlando o Acesso a Recursos do Sistema.

Para obter mais informações, consulte as páginas do manual systemctl(1) e systemd-cgls(1). Consulte também Usando o Systemd para Gerenciar Grupos de Controle.

Mostra como usar systemctl set-property e systemd-run para atribuir limites de CPU e memória a serviços e escopos.

Use o comando systemctl para controlar o acesso de um cgroup aos recursos do sistema, por exemplo:

sudo systemctl [--runtime] set-property httpd CPUShares=512 MemoryLimit=1G

CPUShare controla o acesso aos recursos da CPU. Como o valor padrão é 1024, um valor de 512 reduz pela metade o acesso ao tempo de CPU que os processos no cgroup têm. Da mesma forma, MemoryLimit controla a quantidade máxima de memória que o cgroup pode usar.

Como alternativa, você pode alterar as definições de recursos de um serviço no cabeçalho [Service] no arquivo de configuração do serviço em /usr/lib/systemd/system. Após editar o arquivo, faça com que systemd recarregue seus arquivos de configuração e reinicie o serviço:

sudo systemctl daemon-reload
sudo systemctl restart service

Você pode executar comandos gerais dentro de escopos e usar systemctl para controlar o acesso que esses cgroups transitórios têm aos recursos do sistema. Para executar um comando dentro de um escopo, use o comando systemd-run:

sudo systemd-run --scope --unit=group_name.scope [--slice=slice_name]

Se não desejar criar o grupo no segmento system padrão, é possível especificar outro segmento ou o nome de um novo segmento. O exemplo a seguir executa um comando chamado mymonitor em mymon.scope sob myslice.slice:

sudo systemd-run --scope --unit=mymon.scope --slice=myslice mymonitor

Running as unit mymon.scope.

Você pode, então, usar systemctl para controlar o acesso que um escopo tem aos recursos do sistema da mesma forma que para um serviço. No entanto, ao contrário de um serviço, você deve especificar a extensão .scope, por exemplo:

sudo systemctl --runtime set-property mymon.scope CPUShares=256

Para obter mais informações, consulte Usando o Systemd para Gerenciar Grupos de Controle e as páginas manuais systemctl(1), systemd-cgls(1) e systemd.resource-control(5).

Descreve como substituir arquivos de unidade empacotados e criar snippets drop-in em /etc/systemd/system.

Para alterar a configuração dos serviços systemd, copie os arquivos com as extensões .service, .target, .mount e .socket de /usr/lib/systemd/system para /etc/systemd/system.

Após ter copiado os arquivos, você poderá editar as versões em /etc/systemd/system.

Os arquivos do /etc/systemd/system têm precedência sobre as versões do /usr/lib/systemd/system. Os arquivos no /etc/systemd/system não são substituídos quando você atualiza um pacote que toca em arquivos no /usr/lib/systemd/system.

Para reverter para a configuração padrão do systemd de um serviço específico, você pode renomear ou excluir as cópias no /etc/systemd/system.

Outra abordagem para alterar a configuração de um serviço é criar um arquivo drop-in. Com esta abordagem, você pode preservar a unidade original enquanto altera parâmetros específicos da unidade.

Crie arquivos drop-in em /etc/systemd/system/unit_name.d/, onde o diretório unit_name.d é uma unidade existente, em seguida, dê aos arquivos drop-in uma extensão de arquivo .conf.

Por exemplo: /etc/systemd/system/unit_name.d/name_of_drop-in.conf. systemd lê o arquivo .conf e aplica as configurações à unidade original.

As seções a seguir descrevem as diferentes partes de um arquivo de unidade de serviço que você pode editar e personalizar para um sistema.