- Master systemctl: estados iniciar/parar, habilitar/desabilitar e está ativo/está habilitado/está com falha.
- Explorar e depurar: list-units, list-unit-files, dependencies, journalctl e systemd-analyze.
- Otimize com alvos, substituições e práticas recomendadas (ExecReload, RestartSec, caminhos absolutos).
- Aplica-se ao WSL e outras distros; entende limitações, críticas e compatibilidade com outros inits.
Nos sistemas Linux modernos , o systemd e sua ferramenta systemctl são essenciais para o gerenciamento e inicialização de serviços . Se você trabalha diariamente com servidores ou desktops, dominar essas ferramentas permitirá que você inicie, pare, depure e automatize serviços com facilidade.
Ao longo deste guia, você encontrará uma visão geral abrangente e prática do gerenciamento de serviços com o systemd : desde o básico (iniciar, parar, habilitar) até opções avançadas, como isolar alvos, editar unidades com sobrescritas, analisar processos de inicialização e até mesmo habilitá-lo no WSL. Tudo isso é abordado considerando a compatibilidade entre distribuições e outros sistemas init, para que você não seja pego de surpresa.
O que é systemd e como ele organiza o sistema?
Em resumo, o systemd é o sistema init e gerenciador de serviços que é executado com PID 1 e coordena a inicialização e o ciclo de vida dos processos do usuário. Dentro de seu ecossistema, os componentes principais são as "unidades", que representam recursos gerenciáveis, como serviços, sockets, pontos de montagem, dispositivos ou alvos.
As unidades são descritas com arquivos unitários com sufixos que indicam seu tipo: .service (serviços), .socket (sockets), .target (estados do sistema), entre outros. Esses arquivos residem em caminhos como /lib/systemd/system y /etc/systemd/system, e pode ser visualizado, listado e modificado com systemctl.
Além do systemctl, o ecossistema é complementado por utilitários como journalctl (logs), loginctl (sessões), hostnamectl , localectl , timedatectl e ferramentas de inspeção como o systemd-cgls . Tudo isso contribui para uma administração mais refinada e centralizada.
Se você precisar alterar as configurações globais padrão, você pode editar /etc/systemd/system.conf (por exemplo, DefaultTimeoutStartSec) e assim por diante substituir valores de compilação em todo o sistema sem tocar unidade por unidade.
Iniciar, parar, reiniciar e recarregar serviços
A vida cotidiana começa com o básico: iniciar e parar serviços. Usos sudo systemctl start nombre.service para começar e sudo systemctl stop nombre.service para parar. O sufixo .service é opcional; o systemd é inteligente e geralmente o infere. Em ambientes Windows lá comandos equivalentes para Controle processos e serviços no Windows.
Quando você faz alterações de configuração, geralmente isso afeta reiniciar com sudo systemctl restart nombre.serviceSe o serviço suportar recarga a quente, você economiza uma interrupção com sudo systemctl reloadSe você não sabe se deve recarregar ou não, puxe recarregar ou reiniciar e pronto.
Observe que alguns daemons são destinados a reaparecer após uma parada devido à sua própria política de reinicialização. Isso é comum em peças de infraestrutura, como systemd-networkd, então não se surpreenda se ele se levantar novamente.
Cuidado com as variantes entre as distros: no Ubuntu desktop é comum trabalhar com NetworkManager, então comandos como status de rede podem ser consultados em NetworkManager.service em vez de systemd-networkd.service.
Habilitar, desabilitar e verificar status
Para um serviço iniciar automaticamente com o sistema, use sudo systemctl enable nombre.service. Isso cria links simbólicos do seu arquivo de unidade para os caminhos .../target.wants do alvo correspondente. No Windows, existem diretrizes sobre quais serviços não devem ser tocados, por exemplo Serviços do Windows 11 que você não deve desabilitar.
Se você não quiser isso na inicialização, desabilite-o com sudo systemctl disableLembre-se de que habilitar/desabilitar não inicia ou para o serviço na sessão atual; você combinará habilitar/desabilitar com iniciar/parar conforme apropriado.
Para verificar o status em detalhes, status systemctl Ele fornece carga, atividade, PID, cgroup e as últimas linhas de log da unidade. Se você quiser apenas um veredito rápido: systemctl is-active (correndo ou não), systemctl is-enabled (ativado ou desativado) e systemctl is-failed (falha, inativo, desconhecido) com códigos de saída úteis para scripts.
Explore o sistema: list-units e list-unit-files
Quando você precisa de uma visão geral, o comando `systemctl list-units` exibe as unidades ativas. Você verá colunas para UNIDADE, CARGA, ATIVA, SUB e DESCRIÇÃO, fornecendo uma visão geral rápida do que está acontecendo. No Windows, o comando `tasklist` fornece uma visualização semelhante.
Se você quiser ser mais exaustivo, adicione -tudo Para incluir inativos, filtre por status com --state= e por tipo com --type=serviceDessa forma, você pode listar, por exemplo, todas as unidades de serviço, independentemente de sua atividade.
Para verificar o que está instalado e sua política de inicialização, o comando `systemctl list-unit-files` lista os arquivos de unidade com seus respectivos estados: habilitado, desabilitado, estático ou mascarado. "Estático" indica unidades sem seção `<unistd>`, destinadas a dependências ou execução ocasional.
Inspecionar unidades, dependências e propriedades
Usar `systemctl cat nome.serviço` mostrará o arquivo de unidade exato que o systemd carregou (incluindo as sobrescritas). Isso é ideal para verificar quais diretivas estão realmente ativas.
As dependências são exibidas com dependências da lista systemctl. Você pode adicionar --all para recursão, --reverse para dependências inversas, ou --before/--after para a ordem relativa entre unidades.
Se você precisar de detalhes de baixo nível, systemctl mostrar despeja propriedades-chave no formato clave=valor. Para algo específico, use -p Propiedad e você obtém apenas o que lhe interessa (por exemplo, conflitos ou relacionamentos de ordem).
Quando um serviço nem deveria ser iniciado, mascare-o com sudo systemctl mask nombre.service (aponta para /dev/null). Então apenas unmask Ele retorna ao seu estado anterior. Uma máscara bloqueia inicializações manuais e automáticas. Em ambientes Windows, você também pode restaurar serviços danificados a partir do console de Serviços, por exemplo. Restaurar serviços excluídos de services.msc.
Unidades de edição: substituições e recarregamentos de daemon
Para personalizar sem tocar no arquivo original, systemctl editar nome.serviço abre uma substituição em /etc/systemd/system/nombre.service.d/override.confO que você colocar lá prevalece sem perder a base do fornecedor.
Se você quiser reescrever a unidade inteira, use -completo e salvará uma cópia em /etc/systemd/system. Ao remover substituições ou unidades personalizadas, lembre-se recarregar o daemon com sudo systemctl daemon-reload para que pare de referenciá-los.
Se você não precisar mais de suas alterações, você pode exclua o diretório .d da substituição ou da unidade completa em /etc/systemd/system. Depois disso, um daemon-reload e o sistema retornará às definições do sistema base.
Alvos e relacionamento com níveis de execução
Os alvos representam estados do sistema (por exemplo, multi-user.target ou graphical.target) e agrupam as unidades necessárias para atingir esse estado. Eles são semelhantes aos antigos níveis de execução, mas são mais flexíveis e componíveis.
Consulte o alvo padrão com systemctl get-default e mude com conjunto padrão (por exemplo, graphical.target para começar em um ambiente gráfico). Você pode listar os alvos instalados com list-unit-files --type=target e ativos com list-units --type=target.
Se você precisar fazer um trajeto drástico, isolar interrompe o que não pertence ao alvo e ativa suas dependências. Antes de fazer isso, é uma boa ideia revisar list-dependencies do alvo para não derrubar acidentalmente algo crítico.
Além disso, o systemctl expõe atalhos com avisos para usuários conectados: resgatar (modo de usuário único), parar, desligar y reinicialização. Em muitas máquinas, comandos tradicionais como reboot já estão vinculados ao systemd.
| Nível de execução SysV | Sistema de destino | Descrição |
|---|---|---|
| 0 | runlevel0.target / poweroff.target | Desligue o sistema completamente. |
| 1, s (único) | runlevel1.target / resgate.target | Modo de resgate, usuário único. |
| 2-4 | runlevel2-4.target / multiusuário.target | Multi usuário sem interface gráfica. |
| 3 | runlevel3.target / multiusuário.target | Modo de servidor típico sem GUI. |
| 5 | runlevel5.target / gráfico.target | Multiusuário com GUI. |
| 6 | runlevel6.target / reboot.target | Reiniciar a máquina. |
| kit | Emergency.target | Concha de emergência mínimo. |
Crie seu próprio serviço (.service) passo a passo
Para um serviço personalizado, crie a unidade em /etc/systemd/system. Por exemplo, ttrssupdate.service Ele pode conter uma descrição, dependências, o usuário de execução e o comando a ser iniciado.
Um exemplo típico seria algo como isto (ajuste os caminhos reais): com Description, After, User, ExecStart e WantedBy, você define os elementos essenciais para que o sistema multiusuário seja iniciado.
Em relação às licenças e à propriedade, é importante que o arquivo pertence a raiz e ter permissões consistentes. Evite permissões excessivamente permissivas; embora alguns exemplos mostrem chmod 777, a prática recomendada é mais restritiva para não abrir portas para problemas de segurança.
Após criar ou modificar a unidade, execute sudo systemctl daemon-reload, permite com enable e começa com start. A partir daí, você pode Pare, restart e consultar estado. Para depurar, journalctl -u tu-servicio.service vai te mostrar o toras associados.
Equivalentes ao SysV e outros inits
Se você vem do SysV, pense em systemctl iniciar/parar/reiniciar/recarregar/status como substitutos para service nombre start/stop/.... Para a parte inicial, habilitar desabilitar substitui chkconfig on/offe arquivos de unidade de lista fornece uma visão geral do que é ativado.
Em sistemas mais antigos, você pode encontrar ` service --status-all` , que lista os daemons com sinalizadores como (ativo), (inativo) ou (desconhecido). Com o Upstart (Ubuntu 14.04, RHEL6), `initctl list` é usado para visualizar estados como `running`, `stopped` ou `waiting`.
Em ambientes que utilizam OpenRCGenericName (Gentoo, Alpino), rc-status Exibe serviços por nível de execução com status iniciado/parado/com falha/travado. Você pode até verificar o nível de execução atual com rc runlevel. Para tarefas avançadas de gerenciamento de processos no Windows, também existem ferramentas de terceiros, por exemplo Use o Process Hacker para gerenciar prioridades.
Diagnósticos, logs e desempenho de inicialização
Para verificar definições, o systemd-analyze fornece funções de verificação e análise. Você pode obter um instantâneo do processo de inicialização, ver o que levou mais tempo e gerar um SVG.
Comandos comuns: systemd-analyse culpa (vezes por serviço), systemd-analisar cadeia crítica (cadeia crítica de dependências) e gráfico systemd-analyze (gera um .svg com o cronograma de inicialização).
Quando um serviço falha, inicie com `journalctl -u nome.do.serviço` para ver erros e avisos. Você pode listar as unidades com falha e, se o desligamento ou a reinicialização demorarem muito, verifique se há tarefas travadas e cancele-as antes de tentar novamente.
Se você editar ou criar novas unidades, não se esqueça de executar o comando `systemd-analyze verify` para detectar erros de sintaxe ou referências a arquivos inexistentes antes de habilitar e iniciar o serviço.
Boas práticas de gestão
Em arquivos de unidade, sempre use caminhos absolutos em ExecStart/ExecReload e arquivos de configuração. Não confie em variáveis de ambiente como $PATH porque o systemd não os considerará como seu shell faria.
Definir ExecReload se o seu serviço suporta recarga dinâmica. Desta forma você pode usar systemctl reload quente sem reinicializar, o que é essencial para servidores com alta disponibilidade.
Configure o RestartSec em conjunto com suas políticas de reinicialização para evitar ciclos frenéticos de reinicialização. Um pequeno atraso ajuda a estabilizar dependências e recursos compartilhados.
Documentar e monitorar: salvar listas como systemctl list-unit-files –type service –all > services.txt, mapeia dependências com list-dependencies --reverse e monitora o status e o consumo. Complemente com soluções Prometheus/Grafana ou APM, se necessário.
Em sistemas remotos críticos, desative o modo de emergência se ele puder causar a perda de acesso à rede devido a uma configuração incorreta. E, claro, valide as alterações em ambiente de teste antes de implementá-las em produção.
Compatibilidade, adoção e visão de negócio
Embora o systemd domine a maioria das distribuições atualmente , ele não é universal. O Fedora o incorporou desde cedo; o Debian o utiliza desde a versão 8; o RHEL e o CentOS desde o RHEL 7; o Ubuntu o adotou na versão 15.04; o Arch e o openSUSE o utilizam há anos, entre outros.
Nem tudo foram elogios: sua complexidade e abrangência foram alvo de críticas , assim como seu potencial para criar dependências dentro do ecossistema e um certo afastamento da filosofia minimalista do Unix . Para administradores iniciantes, a curva de aprendizado pode parecer íngreme.
Entre as desvantagens práticas estão: permissões e segurança mal configuradas, possíveis conflitos de dependência, inicializações mais lentas devido a tempos limite mal ajustados ou falhas após atualizações se os discos não forem mantidos.
Dito isso, em ambientes corporativos, proporciona consistência, telemetria e controle . Sua modularidade, registro integrado e modelagem declarativa de dependências facilitam a operação em escala e reduzem o tempo médio de reparo.
Systemd no WSL: como habilitá-lo e o que ele muda
Se você estiver trabalhando no Windows com WSL 2, agora você pode habilitar systemd para chegar ainda mais perto de um Linux bare-metal. No Ubuntu atual instalado com wsl --install Ele já vem por padrão.
Para outras distros no WSL 2, edite /etc/wsl.conf e acrescenta: em uma linha e systemd=true em outro. Feche e execute wsl.exe –desligamento en PowerShell para reiniciar o WSL; quando você retornar, verifique com systemctl status.
Em sistemas Debian/Ubuntu/Kali, certifique-se de ter o systemd e o systemd-sysv instalados. Importante: Ao atribuir o PID 1 ao systemd, o WSL ajusta sua arquitetura interna; no entanto, os serviços não mantêm a instância do WSL ativa indefinidamente, como antes.
Para qualquer pessoa que esteja desenvolvendo com snaps, microk8s ou outros componentes que dependem do systemd, essa integração reduz o atrito e aproxima o comportamento do que você verá na produção.
Vale lembrar que o systemd também oferece utilitários complementares como o journalctl para registro em diário e o systemd-analyze para criação de perfis de inicialização e verificação de unidades. Com um pouco de organização e algumas boas práticas, ele se torna uma ferramenta muito poderosa para administradores e engenheiros de DevOps.
Escritor apaixonado pelo mundo dos bytes e da tecnologia em geral. Adoro compartilhar meu conhecimento por meio da escrita, e é isso que farei neste blog, mostrar a vocês tudo o que há de mais interessante sobre gadgets, software, hardware, tendências tecnológicas e muito mais. Meu objetivo é ajudá-lo a navegar no mundo digital de uma forma simples e divertida.