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 — 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.