systemctl: todas as formas de listar serviços no Linux

O comando essencial: systemctl list-units --type=service

Em qualquer distribuição que use systemd (Ubuntu desde a 15.04, Debian desde a 8, RHEL e CentOS desde a 7, além de Fedora, Arch e openSUSE), cada serviço é uma unit do systemd, e systemctl é a ferramenta que as lista:

systemctl list-units --type=service

Por omissão, isto mostra todas as units de serviço que o systemd tem atualmente em memória: serviços ativos, com tarefas em fila ou que falharam. Não mostra os serviços que estão instalados mas nunca foram iniciados. Quando a saída é maior do que o terminal, o systemctl encaminha-a para um paginador (less). Prima q para sair, ou adicione --no-pager para escrever diretamente no stdout.

Cada linha tem cinco colunas:

• UNIT: o nome da unit, por exemplo ssh.service. É exatamente o nome que passa a systemctl status, start e stop.
• LOAD: indica se o ficheiro da unit foi interpretado corretamente (loaded, not-found, bad-setting, error ou masked).
• ACTIVE: o estado de alto nível (active, inactive, activating, deactivating ou failed).
• SUB: o estado de baixo nível, específico do tipo de unit (um serviço pode estar running, exited, dead, e assim por diante).
• DESCRIPTION: o texto legível definido no ficheiro da unit.

Leia o par ACTIVE/SUB em conjunto: active (running) significa que existe um processo em execução neste momento, enquanto active (exited) significa que um serviço oneshot correu com êxito e terminou. Isso é normal em tarefas de configuração, não é um problema a corrigir.

Filtragem: em execução, falhados ou tudo

A opção --state= filtra por qualquer valor de LOAD, ACTIVE ou SUB e aceita listas separadas por vírgulas:

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed é o atalho integrado para o filtro de falhas e vale a pena executá-lo por reflexo em qualquer máquina onde entre. Para uma saída legível por máquinas, --no-legend remove o cabeçalho e as linhas de resumo e --plain remove os marcadores, mantendo as colunas estáveis para awk ou cut. Para procurar por nome, use um pipe para o grep: systemctl list-units --type=service --all --no-pager | grep ssh.

O que arranca no boot: systemctl list-unit-files

list-units responde a "o que está a correr agora?". Para responder a "o que vai arrancar no boot?", liste em vez disso os ficheiros de unit instalados no disco:

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Aqui a coluna STATE descreve a configuração de arranque, não o estado em execução:

• enabled: arranca automaticamente no boot (ou no seu gatilho, no caso de serviços ativados por socket/timer).
• disabled: está instalado, mas nada o inicia automaticamente.
• static: não tem secção [Install]; só corre como dependência de outra unit e não pode ser ativado diretamente.
• masked: ligado por symlink a /dev/null; o systemd recusa-se a iniciá-lo.
• generated: criado em tempo de execução por um gerador, normalmente a partir de um script de init antigo.

As versões recentes do systemd mostram também uma coluna de preset (VENDOR PRESET ou PRESET, dependendo da versão) com o valor por omissão da distribuição. A armadilha a evitar: ativado não significa em execução, e desativado não significa parado. Um serviço pode estar desativado e a correr porque alguém o iniciou à mão, ou ativado e morto porque falhou. Quando isso importa, confirme nas duas listagens.

Um serviço de cada vez: status, is-active, is-enabled

Quando um serviço lhe chama a atenção, aprofunde:

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

O status mostra o quadro completo: estado ACTIVE/SUB, PID principal, tempo em execução, memória usada, a árvore de processos do cgroup e as últimas dez linhas do journal. Quando dez linhas não bastam, vá diretamente ao journal com journalctl -xeu nginx (-u filtra por unit, -e salta para o fim, -x acrescenta texto explicativo).

Os comandos is-* foram feitos para scripts: devolvem uma única palavra e definem o código de saída em consequência; is-active sai com 0 apenas quando a unit está ativa, e is-enabled sai com valor diferente de zero para units desativadas ou mascaradas. Adicione --quiet para suprimir a saída e ficar só com o código de saída.

Todos os comandos de listagem acima funcionam com um utilizador sem privilégios. Gerir efetivamente os serviços (start, stop, enable, disable) exige root, por isso vale a pena compreender como funcionam o sudo e a mudança de utilizador no Ubuntu antes de ir além da leitura do estado. Note também que as units de nível de utilizador vivem num gestor separado: systemctl --user list-units --type=service lista os serviços que correm na sua própria sessão, e é por isso que alguns serviços parecem "desaparecidos" na listagem do sistema.

Resumo: as listagens que vai usar de facto

Fluxos de trabalho reais

1. Encontrar o serviço que falha repetidamente

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Comece de forma ampla com --failed, depois leia a saída do status para ver o código de saída e as últimas linhas de log, e por fim vá ao journal para obter o rastreio completo. Assim que a causa raiz estiver corrigida e o serviço estiver de novo a funcionar, reset-failed limpa a entrada de falha antiga para que a próxima verificação comece limpa.

2. Auditar o que vai arrancar no próximo boot

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

O primeiro comando dá-lhe uma lista limpa de tudo o que arranca automaticamente, útil antes de reforçar a segurança de um servidor ou de procurar algo que instalou há meses e esqueceu. Já systemd-analyze blame mostra quanto tempo cada unit levou no último boot, e é aí que os serviços lentos a arrancar se destacam de imediato.

3. Comandos de uma linha para scripts e monitorização

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p devolve pares Key=Value cujo formato nunca muda entre versões, e a saída em JSON alimenta diretamente o jq. Se se vê a repetir as mesmas verificações em cada sessão, junte-as num pequeno script. O nosso guia sobre ficheiros .sh e shell scripting explica como transformar exatamente este tipo de trecho numa ferramenta reutilizável.

Sem systemd? service --status-all e OpenRC

Antes de assumir que o systemctl existe, confirme o que a máquina realmente usa: verificar o sistema operativo e a versão pela linha de comandos leva dez segundos e diz-lhe se está ou não numa distribuição com systemd. Se o systemctl não existir, está em SysV init ou OpenRC:

service --status-all

No Debian e no Ubuntu, isto percorre /etc/init.d e mostra [ + ] para os serviços em execução, [ - ] para os parados e [ ? ] para os scripts sem comando de status. Continua a funcionar em distribuições com systemd através de uma camada de compatibilidade, mas só vê scripts de init, por isso aí prefira o systemctl. No Alpine e no Gentoo, o OpenRC é o sistema de init: rc-status lista os serviços do runlevel atual e rc-update show lista o que cada runlevel arranca.

Tudo o que está acima pressupõe que tem uma máquina Linux onde é root e pode iniciar, quebrar e reparar serviços livremente. Se precisa de uma para praticar (ou de uma máquina limpa para alojar cargas de trabalho reais), um VPS Linux com acesso root completo da rdp.monster inclui CPU e RAM dedicados, largura de banda ilimitada (fair-use), sem KYC, e é entregue cerca de 10 segundos após a confirmação do pagamento, para que possa estar a executar systemctl list-units no seu próprio servidor em menos de um minuto.

Perguntas frequentes

Por que motivo um serviço aparece como active (exited) em vez de active (running)?

É um serviço oneshot que correu com êxito e terminou. Não é um erro.

Os serviços com Type=oneshot (ou RemainAfterExit=yes) executam uma tarefa uma vez (montagens, configuração da firewall, limpezas) e terminam. O systemd reporta então active (exited): a unit teve êxito e é considerada "ligada", mas nenhum processo permanece. Só daemons como o nginx ou o sshd mostram active (running). Se um serviço que espera ser um daemon aparece como exited, veja o respetivo ficheiro de unit com systemctl cat name.service para perceber como está declarado.

O que significam os pontos coloridos na saída do systemctl?

Verde significa ativo, branco significa inativo e vermelho significa falhado ou em erro.

O marcador antes do nome de uma unit em systemctl status e systemctl list-units é um indicador rápido de estado: verde para ativo, branco para inativo ou a desativar e vermelho para estados de falha ou erro. As linhas com falhas também aparecem destacadas a vermelho nas listagens, o que torna systemctl --failed muito fácil de ler. Em scripts ou logs onde os códigos de cor incomodam, adicione --plain ou encaminhe a saída por um pipe, e as decorações desaparecem.

Existe um equivalente de chkconfig --list no systemctl?

Sim, systemctl list-unit-files --type=service substitui chkconfig --list.

No RHEL e no CentOS 7 ou mais recentes, chkconfig --list foi substituído por systemctl list-unit-files --type=service, que mostra todos os serviços instalados e se estão enabled, disabled, static ou masked. Para um único serviço, systemctl is-enabled name substitui chkconfig name, e systemctl enable name substitui chkconfig name on. O comando antigo pode ainda existir como camada de compatibilidade, mas só cobre os scripts SysV legados.

Como impeço um serviço de arrancar no boot?

Use systemctl disable para o retirar do arranque, ou mask para o bloquear por completo.

Execute sudo systemctl disable name para remover o symlink de arranque; adicione --now para também o parar imediatamente. Um serviço desativado pode ainda ser iniciado manualmente ou puxado como dependência de outra unit. Se quiser que nunca arranque, use sudo systemctl mask name, que liga a unit a /dev/null para que todas as tentativas de arranque falhem. Pode reverter mais tarde com systemctl unmask. Confirme o resultado com systemctl is-enabled name.