Linux / Comando systemctl: consultar e gerenciar serviços systemd

systemctl consulta e controla serviços e outras unidades gerenciadas por systemd. Para investigar uma falha, comece pelo estado atual e pelos logs; separe iniciar um serviço agora com start de configurar sua ativação com enable, pois uma ação não implica automaticamente a outra.

Uma unidade é um recurso que systemd gerencia, como um serviço .service, um temporizador .timer ou um socket .socket. Active indica o estado de ativação; enabled descreve uma configuração de habilitação. Nenhum desses termos, sozinho, comprova que uma aplicação esteja atendendo corretamente às solicitações. Para o contexto, consulte o guia de serviços, inicialização e logs do systemd em inglês.

Sintaxe e preparação

systemctl [opções] comando [unidade]

Os colchetes são uma notação de sintaxe. Escolha um comando e o nome real da unidade; não digite os colchetes. Confira systemctl --version, systemctl --help e man systemctl no sistema administrado.

As consultas aos serviços de sistema exigem acesso ao gerenciador systemd correspondente. Ter o executável instalado não garante que um ambiente mínimo ou contêiner esteja executando systemd como gerenciador do sistema. Um erro de conexão ao barramento ou ao gerenciador não significa que o serviço esteja parado. As unidades do usuário, consultadas com --user, pertencem a outro escopo; este artigo trata do gerenciador do sistema.

Consultar o estado de um serviço

systemctl status sshd.service

Sshd.service é um exemplo: confirme o nome usado pela distribuição, que pode ser diferente. Consulte systemctl list-unit-files --type=service para procurar definições instaladas e verifique a unidade correta antes de qualquer mudança. Não reinicie o serviço de acesso remoto apenas para descobrir seu nome.

Leia separadamente Loaded, que informa o carregamento da definição, Active e seu subestado, e as mensagens recentes disponíveis. Not-found indica que a unidade não foi encontrada; failed indica uma falha registrada. O status apresenta um resumo para leitura humana, não todo o histórico nem um formato estável para scripts.

Para investigar a unidade deste exemplo, consulte journalctl -u sshd.service -b, que limita a busca à inicialização atual. A disponibilidade dos registros depende da coleta, retenção e permissão de leitura. O guia de journalctl em inglês apresenta outras consultas. Se o paginador abrir no terminal, pressione q para sair.

Consultar a ativação atual

systemctl is-active sshd.service

Is-active imprime o estado atual e retorna zero quando a unidade consultada está ativa. Leia também a saída e o erro: um resultado não zero pode indicar inatividade, unidade inexistente ou falha na consulta. Não transforme qualquer erro em um diagnóstico de serviço parado.

Consultar a habilitação

systemctl is-enabled sshd.service

Is-enabled consulta a configuração da unidade, independentemente de ela estar ativa agora. Enabled não é uma confirmação de início bem-sucedido nem de funcionamento da aplicação. Disabled também não impede necessariamente que a unidade seja iniciada manualmente ou acionada por outra unidade.

Existem outros estados, como static, indirect, alias e masked. Static, por exemplo, pode retornar zero em is-enabled mesmo sem a unidade estar habilitada da maneira habitual; masked impede sua ativação. Em scripts, interprete o texto conforme a tabela de estados e comandos de systemctl, em vez de traduzir todo retorno zero simplesmente como enabled.

Interpretar active sem confundir com enabled

Repita a consulta para comparar seu resultado com a configuração de habilitação:

systemctl is-active sshd.service

Um exemplo ilustrativo de saída é:

active

Active significa que a unidade é considerada ativa pelo gerenciador. Em um serviço oneshot com RemainAfterExit=yes, ela pode continuar ativa mesmo depois de o processo terminar com sucesso. Portanto, active não equivale sempre a um processo em execução e não substitui uma verificação funcional da aplicação.

Start solicita a ativação imediata. Enable cria as ligações previstas para a ativação da unidade, muitas vezes na inicialização. Enable sozinho não executa start; disable sozinho não executa stop. A opção --now combina a operação de habilitação ou desabilitação com iniciar ou parar, quando aplicável.

Comandos principais

Reload e daemon-reload têm alvos diferentes. Se alterar a definição de unidade em disco, sudo systemctl daemon-reload faz o gerenciador reler as definições e dependências; não reinicia automaticamente a aplicação. Reload pede ao próprio serviço que releia sua configuração, se houver suporte. Depois da alteração, escolha a ação adequada à aplicação e confira estado, logs e funcionamento.

Stop ou restart de SSH e de serviços web pode interromper conexões e pedidos em andamento. Antes de uma mudança real, confira unidade, escopo, autorização, momento de execução e acesso de recuperação. O laboratório abaixo usa uma unidade nova para comparar os estados sem alterar um serviço de produção.

Comparar estados em uma unidade de laboratório

Use uma máquina virtual dedicada com systemd como PID 1, acesso ao gerenciador, /usr/bin/true disponível e uma conta autorizada a administrar essa VM com sudo. O bloco cria /etc/systemd/system/lf-systemctl-lab.service e altera temporariamente sua habilitação. Leia também a limpeza antes de executar; se já existir qualquer unidade, alias, arquivo ou complemento com esse nome, interrompa e escolha outro nome de laboratório em todos os pontos.

Antes da criação, confira os diretórios de unidades e complementos da VM, inclusive os de execução e os do fornecedor; não permita alterações concorrentes durante o exercício. O bloco confirma o PID 1, exige LoadState=not-found, verifica os caminhos locais e cria o arquivo sem sobrescrever um existente. Se a consulta ou uma condição falhar, ele para. Esses controles não substituem conferir a identidade do ambiente e do nome escolhido.

(
set -eu
unit=lf-systemctl-lab.service
file=/etc/systemd/system/$unit
sudo -v
[ "$(cat /proc/1/comm)" = systemd ]
[ -x /usr/bin/true ]
load_state=$(systemctl show --property=LoadState --value "$unit")
if [ "$load_state" != not-found ]; then
    printf 'Nome de unidade indisponivel; interrompa o laboratorio.\n' >&2
    exit 1
fi
sudo sh -eu -c '
for p in "$1" "$1.d" "/etc/systemd/system/multi-user.target.wants/$2"; do
    if [ -e "$p" ] || [ -L "$p" ]; then
        printf "Caminho existente: %s\n" "$p" >&2
        exit 1
    fi
done
set -C
cat > "$1"
' sh "$file" "$unit" <<'EOF'
[Unit]
Description=Laboratorio de estados systemctl do Linux Factory
[Service]
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
systemctl is-active "$unit"
sudo systemctl enable "$unit"
systemctl is-enabled "$unit"
sudo systemctl stop "$unit"
if state=$(systemctl is-active "$unit"); then
    printf 'A unidade ainda esta ativa; verifique antes de continuar.\n' >&2
    exit 1
fi
[ "$state" = inactive ]
printf '%s\n' "$state"
systemctl is-enabled "$unit"
sudo systemctl disable "$unit"
if state=$(systemctl is-enabled "$unit"); then
    printf 'Estado de habilitacao inesperado; interrompa o laboratorio.\n' >&2
    exit 1
fi
[ "$state" = disabled ]
printf '%s\n' "$state"
)

O texto da unidade usa Type=oneshot e executa /usr/bin/true. RemainAfterExit=yes faz a unidade permanecer ativa depois da conclusão bem-sucedida. A documentação oficial de serviços systemd explica esse comportamento. WantedBy=multi-user.target fornece a relação usada por enable.

1. Depois de start, a consulta deve mostrar active.
2. Depois de enable, is-enabled deve mostrar enabled.
3. Depois de stop, is-active deve mostrar inactive, enquanto is-enabled continua mostrando enabled.
4. Depois de disable, is-enabled deve mostrar disabled.

O bloco trata explicitamente os retornos não zero esperados para inactive e disabled e confirma o texto recebido. Uma mensagem de falha de barramento ou outro estado não deve ser aceita como resultado normal. A verificação da definição com systemd-analyze verify procura problemas na unidade, mas não comprova todos os resultados de execução.

Limpar o laboratório e verificar o resultado

1. Confira systemctl cat lf-systemctl-lab.service e os caminhos mostrados. A definição deve ser exatamente a criada neste exercício, sem edição concorrente ou complemento inesperado. Se houver diferença, interrompa a limpeza e investigue.
2. Somente para essa unidade de laboratório, execute sudo systemctl disable --now lf-systemctl-lab.service e confirme que ela está parada e desabilitada. Não aplique o comando a SSH ou a outro serviço real.
3. Depois de confirmar a identidade do arquivo regular criado aqui, remova somente esse arquivo com sudo rm -- /etc/systemd/system/lf-systemctl-lab.service. Não remova diretórios de unidades nem arquivos preexistentes.
4. Execute sudo systemctl daemon-reload e confira novamente a ausência da definição e de sua habilitação. Uma consulta a uma unidade removida pode retornar erro de não encontrada; isso é diferente de uma falha do gerenciador.

Se o bloco parar após criar o arquivo ou habilitar a unidade, não o execute novamente às cegas. Examine o mesmo nome e o arquivo criado, confira o último passo concluído e faça a limpeza desse alvo após verificar sua identidade. Não use um comando amplo de limpeza de serviços.

No ambiente disponível para verificação, Bash 5.3.9 do Git para Windows, systemctl, systemd-analyze e journalctl não foram encontrados. As quatro consultas de estado dos exemplos retornaram 127. A sintaxe dos comandos e do bloco foi conferida, mas o laboratório não foi executado em um gerenciador Linux: active, enabled, inactive e disabled são resultados esperados segundo a documentação, não medições feitas nesta máquina. Nenhum sudo foi executado e nenhum serviço ou arquivo de sistema foi alterado.

Pergunta frequente

Systemctl enable inicia o serviço imediatamente?

Enable sozinho configura a habilitação e não inicia o serviço. Para executar agora, é necessário start ou a combinação enable --now, quando apropriada e autorizada. Confira separadamente o estado de ativação, a habilitação e o funcionamento da aplicação.