Tutorial completo do comando systemctl no Linux

Dominar o systemctl e o systemd é praticamente obrigatório hoje em dia para quem administra servidores ou sistemas Linux modernos. Essa ferramenta é a porta de entrada para controlar quais serviços iniciam, como iniciam, o que falhou e o estado atual do sistema a qualquer momento. Depois de aprender a usá-la, você evitará muitas dores de cabeça e reinicializações desnecessárias.

Ao longo deste guia, você verá, de forma organizada e com exemplos, como usar o systemctl para gerenciar serviços, unidades e alvos ; como listar o que está acontecendo no sistema; como editar unidades sem causar problemas; o que significam estados como `enabled` , `masked` e `static` ; e também dicas para desligar, reiniciar ou alternar do modo gráfico para o modo texto com um único comando. Tudo isso é apresentado em espanhol (da Espanha) de forma clara e prática , projetado para que você possa aplicar o que lê a qualquer distribuição baseada em systemd (Ubuntu, Debian, RHEL, CentOS, Fedora, Arch, etc.).

O que é o systemd e qual o papel do systemctl?

Na maioria das distribuições modernas, o systemd atua como o sistema init e infraestrutura básica . É o processo que inicia logo após o kernel (geralmente com PID 1) e é responsável por iniciar os demais serviços, montar sistemas de arquivos, gerenciar dependências, controlar sessões, registrar eventos e muito mais.

O systemd consiste em daemons, bibliotecas e utilitários que permitem a comunicação com o kernel e o espaço do usuário: ele gerencia grupos de controle (cgroups), sockets, temporizadores, pontos de montagem, configuração básica de rede, sincronização de tempo, resolução de nomes, contêineres e máquinas virtuais , sendo inclusive compatível com scripts SysV e LSB mais antigos, podendo substituir completamente o sysvinit clássico.

Dentro de todo esse ecossistema, o systemctl é o "controle remoto" do systemd . É o utilitário de linha de comando que você usa para:

• Iniciar, parar, reiniciar ou recarregar serviços e outros tipos de unidades.
• Ativar ou desativar unidades para que eles possam começar (ou não) a usar o sistema.
• Verifique o status dos serviços, objetivos e do sistema em geral.
• Editar arquivos de unidade ou visualizar suas dependências e propriedades internas.
• Alterar o estado global do sistema (modo de recuperação, multiusuário, gráfico, desligamento, reinicialização…).

Observe que nem todas as distribuições usam o systemd. Se, ao executar systemctl Você vê uma mensagem como esta: bash: systemctl: command not found Ou algo semelhante; seu sistema provavelmente usa um sistema de inicialização diferente (OpenRC, runit, SysV puro, etc.). Nesse caso, Os comandos neste guia não se aplicam. tal qual.

Unidades e arquivos de unidade no systemd

O conceito fundamental do systemd são as unidades . Uma unidade representa qualquer recurso que o systemd seja capaz de gerenciar: um serviço, um socket, um ponto de montagem, um dispositivo, um objetivo global do sistema, um temporizador, etc. Cada tipo de unidade é identificado por um sufixo no nome do arquivo.

Alguns dos tipos de unidade mais comuns que você encontrará ao trabalhar com systemctl e systemd são:

• .serviço: serviços e daemons (nginx.service, ssh.service, NetworkManager.service…).
• .soquete: soquetes associados a serviços iniciados sob demanda.
• .montar: pontos de montagem do sistema de arquivos.
• .automountConjuntos automáticos ativados para uso.
• .alvo: “estados” do sistema (multi-user.target, graphical.target, rescue.target…).
• .cronômetro: temporizadores que iniciam serviços em horários específicos.
• .dispositivoDispositivos gerenciados pelo udev.
• .caminho: monitores de rota em disco que acionam serviços.

Cada unidade é definida em um arquivo de unidadeque é um arquivo de texto com seções como , , , onde a descrição, as dependências e os comandos são detalhados Bota, usuário que executa o serviço, etc. Esses arquivos geralmente são armazenados em:

• /lib/systemd/system/ o /usr/lib/systemd/system/: unidades que acompanham os pacotes.
• / etc / systemd / system /Unidades definidas ou sobrescritas pelo administrador.

Quando você trabalha com systemctlVocê quase sempre se refere a unidades do tipo .serviçoNo entanto, se você omitir o sufixo, o systemd assume por padrão que você está se referindo a um serviço. Ou seja, systemctl start ssh y systemctl start ssh.service filhos equivalentes.

Existem unidades especiais chamadas modelos, cujo nome inclui @, por exemplo [email protected]Ao instanciar um modelo como [email protected]O que você está fazendo é criar um uma instância específica passando um identificador; dentro do arquivo de unidade, a variável %i Ele é substituído por esse identificador. Isso é comumente usado em túneis SSH, serviços de interface de rede, etc.

Verifique se o seu sistema utiliza o systemd.

Antes de sair digitando comandos sem parar, é uma boa ideia verificar se sua distribuição está realmente usando o systemd como PID 1. Muitos guias sugerem algo tão simples quanto:

pstree | head -5

Se você vir um processo systemd no topo da árvore de diretórios , poderá prosseguir sem problemas. Se vir outro processo init, precisará usar as ferramentas específicas para esse sistema init.

Gerenciamento básico de serviços com systemctl

A operação diária com o systemd normalmente envolve iniciar, parar, reiniciar e recarregar serviços . Esses comandos afetam o estado atual do serviço, não se ele será iniciado automaticamente com o sistema.

Para verificar o status de um serviço , você pode usar:

systemctl status nombre_servicio.service

Por exemplo, para ver como o serviço de rede systemd-networkd está se comportando em um sistema Ubuntu em modo texto:

systemctl status systemd-networkd.service

Este comando exibe informações bastante detalhadas: status (ativo, inativo, falhou…) , quando foi ativado, o PID principal, uso da CPU e algumas mensagens de log recentes que são muito úteis para diagnosticar problemas.

Se você preferir algo mais direto, pode usar estas variações específicas:

• systemctl is-active nome.serviço: indica se está ativo (em execução) ou não.
• systemctl is-enabled nome.serviço: indica se começará do início.
• systemctl falhou nome.serviçoVerifica se entrou em estado de falha.

Por exemplo, para verificar se o systemd-networkd está habilitado na inicialização, você pode executar o seguinte comando:

systemctl is-enabled systemd-networkd.service

E para descobrir se houve alguma falha na inicialização:

systemctl is-failed systemd-networkd.service

Iniciar, parar, reiniciar e recarregar serviços

Para interromper um serviço em execução , o comando típico é:

sudo systemctl stop nombre_servicio.service

Lembre-se de que, como essa é uma ação que afeta o sistema, você precisará... privilégios de administração, normalmente usando sudoEm alguns serviços "teimosos", como o systemd-networkd, interrompê-los fará com que sejam reinicializados imediatamente se houver alguma unidade que os exija e que tenha políticas de reinicialização automática.

Se o serviço for interrompido e você quiser comeceVocê usa o mesmo padrão com start:

sudo systemctl start systemd-networkd.service

Quando você altera um arquivo de configuração e deseja aplicar as alterações, o procedimento mais comum é reiniciar o serviço.

sudo systemctl restart nombre_servicio.service

Muitos serviços permitem recarregar sua configuração sem uma reinicialização completa , evitando a interrupção de conexões ativas. Nesses casos, utiliza-se o seguinte procedimento:

sudo systemctl reload nombre_servicio.service

Se você não tiver certeza se esse serviço oferece recargas, pode tentar:

sudo systemctl reload-or-restart nombre_servicio.service

Com esse comando, o systemctl tenta recarregar primeiro e, se a unidade não implementar a recarga, ele procede com uma reinicialização completa. Isso é muito útil quando você não se lembra do comportamento específico de cada daemon.

Habilitar e desabilitar serviços na inicialização.

Tudo o que vimos até agora afeta apenas a sessão atual . Se você deseja que um serviço seja iniciado automaticamente quando o sistema for inicializado, você precisa habilitá-lo . O comando básico é:

sudo systemctl enable nombre_servicio.service

Ao fazer isso, o systemd cria links simbólicos do arquivo de serviço do sistema (geralmente em /lib/systemd/system o /etc/systemd/system) até um diretório .wants correspondente ao alvo onde deve ser ativado. Por exemplo, algo como:

/etc/systemd/system/multi-user.target.wants/nombre_servicio.service

Se você deseja exatamente o oposto, ou seja, impedir que um serviço seja iniciado automaticamente na próxima inicialização, você o desativa:

sudo systemctl disable nombre_servicio.service

Isso remove os links simbólicos de execução automática, mas não interrompe o serviço que já está em execução . Da mesma forma, habilitar um serviço também não o inicia instantaneamente: a alteração só entrará em vigor após a próxima reinicialização, a menos que você combine o seguinte:

sudo systemctl enable nombre_servicio.service
sudo systemctl start nombre_servicio.service

Algumas distribuições e ferramentas oferecem atalhos para habilitar e iniciar ao mesmo tempo , mas a maneira padrão com o systemctl geralmente é executar ambos os comandos.

Veja o estado geral das unidades

O systemctl não serve apenas para controlar serviços individuais; ele também fornece uma visão geral do sistema . O comando mais comum é:

systemctl list-units

Esta lista mostra todas as unidades ativas que o systemd tem na memória. As colunas principais são:

• UNIDADE: nome da unidade (por exemplo, sshd.service).
• CARGA: se o arquivo da unidade foi carregado corretamente (carregado, não encontrado, erro…).
• ACTIVE: estado geral (ativo, inativo, falhou…).
• SUB: subestado mais descritivo (em execução, encerrado, inativo, falhou…).
• DESCRIÇÃOBreve descrição da unidade.

Se você chamar ` systemctl` sem argumentos , verá praticamente a mesma listagem, pois esse é o seu comportamento padrão. Como apenas as unidades ativas são exibidas, quase tudo aparecerá com `LOAD=loaded` e `ACTIVE=active`.

Para incluir também unidades inativas, você pode adicionar o indicador. --all:

systemctl list-units --all

Você também pode filtrar por estado com --state=Por exemplo, para visualizar apenas as unidades inativas:

systemctl list-units --all --state=inactive

Ou filtre por tipo de unidade com --type=Por exemplo, para visualizar apenas os serviços ativos:

systemctl list-units --type=service

Liste todos os arquivos de unidade instalados

A lista acima mostra apenas as unidades que o systemd tentou carregar. Se você quiser saber todas as unidades existentes no disco , estejam elas em uso ou não, você deve usar:

systemctl list-unit-files

Aqui, o foco está nos próprios arquivos de unidade, não em seu estado na memória. Você verá duas colunas principais: ARQUIVO DE UNIDADE e ESTADO . A coluna ESTADO exibe valores como:

• habilitadoA unidade está configurada para iniciar automaticamente.
• inválidoNão está configurado para inicialização automática.
• estáticoA unidade não possui seção Portanto não pode se ativarGeralmente, trata-se de uma dependência de outras unidades ou da necessidade de executar uma ação específica.
• mascaradoA unidade está completamente bloqueada; não pode ser ligada de forma alguma.

Você também pode filtrar por status, por exemplo, para ver apenas as unidades ativadas:

systemctl list-unit-files --state=enabled

Ou combine vários estados em uma única consulta, separando-os por vírgulas:

systemctl list-unit-files --state=enabled,failed

Veja detalhes, propriedades e dependências de uma unidade.

Se você quiser ver o conteúdo real do arquivo de unidade que o systemd está usando, o comando mais conveniente é:

systemctl cat nombre.service

Isso mostra o arquivo como o systemd o vê, incluindo quaisquer fragmentos de sobrescrita de /etc/systemd/systemÉ muito útil para confirmar se as suas alterações foram efetivamente consideradas.

Para inspecionar a árvore de dependências de uma unidade , você pode usar:

systemctl list-dependencies nombre.service

O resultado é hierárquico, mostrando quais objetivos e serviços impulsionam o serviço em questão. As unidades do tipo .alvo Eles atuam como pontos de agrupamento e, por padrão, são os únicos que mostram suas dependências recursivamente; se você quiser expandir a árvore inteira, adicione --all.

Se o que você precisa saber é As unidades dependem daquela que você indicou., Adicionar --reverse ao comando. E se você quiser se concentrar na ordem de inicialização, as flags --before y --after Elas mostram unidades que devem começar antes ou depois da unidade alvo.

Para visualizar todas as propriedades internas de uma unidade no formato chave=valor, utilize:

systemctl show nombre.service

E se você estiver interessado apenas em um imóvel específico, pode filtrar com -pPor exemplo, para visualizar conflitos do sshd:

systemctl show sshd.service -p Conflicts

Unidades de mascaramento e desmascaramento

Além de desativar, o systemd permite mascarar uma unidade para que seja completamente impossível inicializar a partir dela , seja manualmente ou por meio de dependências em outra unidade. Essa técnica é usada quando você quer ter 100% de certeza de que algo não inicializará, nem mesmo acidentalmente.

O mascaramento é implementado criando um link simbólico para /dev/null em vez do arquivo de unidade real. Para mascarar um serviço, por exemplo, o nginx:

sudo systemctl mask nginx.service

Se você executar então systemctl list-unit-files, você verá que O serviço nginx.service aparece como mascarado.E se você tentar iniciá-lo:

sudo systemctl start nginx.service

Você receberá uma mensagem como: Falha ao iniciar nginx.service: A unidade nginx.service está mascarada. Isso significa que a unidade está bloqueada. Para torná-la utilizável novamente, você precisa desmascará-la.

sudo systemctl unmask nginx.service

Após isso, a unidade retorna ao seu estado anterior (ativada, desativada, estática, etc.) e pode então ser iniciada ou ativada normalmente.

Edite arquivos do disco sem danificar o sistema.

Às vezes, é necessário ajustar o comportamento de um serviço: alterar o usuário que o executa, adicionar opções de linha de comando, modificar dependências… Em vez de editar manualmente os arquivos em /lib/systemd/systemO mais seguro é usar o seu próprio. systemctl para gerar substituições.

O comando básico é:

sudo systemctl edit nombre.service

Isso abre seu editor padrão com um arquivo de fragmento vazioAo salvar e sair, o systemd criará um diretório em /etc/systemd/system/nombre.service.d/ e dentro de um arquivo override.confAo carregar a unidade, o systemd mescla o arquivo original com este fragmento e as diretivas de substituição. eles têm prioridade com base naqueles do arquivo base.

Se você deseja editar o arquivo de unidade inteiro em vez de apenas uma configuração específica, pode fazê-lo com:

sudo systemctl edit --full nombre.service

Neste caso, o que você salvar será gravado em /etc/systemd/system/nombre.serviceque tem precedência sobre a versão do sistema em /lib/systemd/systemÉ uma forma de "clonar" e personalizar completamente uma unidade sem alterar os arquivos que acompanham o pacote.

Se mais tarde você decidir desfazer as alterações, simplesmente exclua o diretório .d da substituição ou do arquivo de serviço modificado em /etc/systemd/system. Por exemplo:

sudo rm -r /etc/systemd/system/nginx.service.d
sudo rm /etc/systemd/system/nginx.service

Após excluir esses itens, é muito importante executar o seguinte comando:

sudo systemctl daemon-reload

Isso força o systemd a recarregar todos os arquivos de unidade , ignorar as substituições removidas e reutilizar as definições originais do sistema.

Metas e adaptação do nível de execução

Os Os alvos do systemd são o equivalente moderno dos níveis de execução. do SysV. São unidades especiais (terminam em .target) que agrupam outras unidades para representar “estados” ou pontos de sincronização do sistema.

Por exemplo:

• multiusuário.destinoModo de console multiusuário, típico de servidores sem ambiente gráfico.
• gráfico.destinoModo gráfico; geralmente depende de multi-user.target e adiciona a camada de interface gráfica.
• resgate.alvoModo de resgate, semelhante ao “modo de usuário único”.
• troca.alvoPonto em que a área de troca está pronta para uso.

As unidades podem declarar relações como WantedBy=, RequiredBy=, Wants=, Requires=, After= com esses objetivos para indicar do que dependem e em que ordem devem ser levantados.

Para descobrir o objetivo padrão do seu sistema (o estado que ele espera atingir em uma inicialização normal), use:

systemctl get-default

Por exemplo, se preferir que o sistema inicie sempre no modo gráfico, pode alterá-lo com:

sudo systemctl set-default graphical.target

Para visualizar todos os alvos instalados no sistema, com seus respectivos status (ativado, desativado…), você pode executar o seguinte comando:

systemctl list-unit-files --type=target

E se você quiser ver quais alvos estão ativos no momento , você faz isso com:

systemctl list-units --type=target

Isolar objetivos e alterar o modo de trabalho

Uma das funcionalidades mais poderosas do systemd é a capacidade de alterar o estado do sistema "isolando" um alvo . Ao realizar um isolamento, o systemd ativa todas as unidades necessárias para esse alvo e desativa aquelas que não se encaixam mais em sua árvore de dependências.

Imagine que você está em um ambiente gráfico ( com o parâmetro `graphical.target` ativo ) e deseja alternar para um ambiente multiusuário somente texto, por exemplo, para realizar tarefas de manutenção. Primeiro, você pode verificar as dependências do parâmetro `multi-user.target`:

systemctl list-dependencies multi-user.target

E quando tiver certeza de que não vai danificar nada crítico, lance:

sudo systemctl isolate multi-user.target

Como `graphical.target` depende de `multi-user.target`, mas não o contrário, isolar o alvo multi-user interromperá todos os serviços associados à camada gráfica , deixando você no modo texto. Essa é uma mudança bastante drástica, portanto, use-a com cautela.

Para eventos muito comuns, o systemctl oferece atalhos convenientes em comparação com a digitação manual de `isolate`. Alguns dos mais usados ​​são:

• sudo systemctl rescue: alterna para o modo de resgate (equivalente a isolar rescue.target) e alerta os usuários conectados.
• sudo systemctl parar: interrompe o sistema (semelhante a desligar a CPU sem cortar a energia).
• sudo systemctl desligamentoDesligue completamente a máquina.
• sudo reinicialização do systemctl: reinicia o sistema.

Normalmente, comandos clássicos como reboot, poweroff o halt Eles estão internamente interligados para se comunicarem com o systemd, portanto, comportam-se de maneira consistente com esses atalhos.

Comandos adicionais essenciais do systemctl

Além de tudo o que foi mencionado acima, existem alguns comandos do systemctl que você deve ter à mão, pois os usará com frequência ao trabalhar com unidades de disco:

Recarregue a configuração do systemd (não os serviços):

sudo systemctl daemon-reload

Sempre que você modifica ou adiciona arquivos de unidade, precisa notificar o systemd para que ele os leia novamente. Este comando não reinicia os serviços ; ele apenas recarrega o banco de dados da unidade.

Verifique o status de um serviço com detalhes (já discutidos):

sudo systemctl status nombre_servicio.service

Aqui você verá o status Carregado, Ativo, PID, tempo de atividade e as mensagens de log mais recentes, o que é essencial para depurar erros.

Ativar e desativar serviços (também visto):

sudo systemctl enable nombre_servicio.service
sudo systemctl disable nombre_servicio.service

Iniciar, parar e reiniciar serviços explicitamente :

sudo systemctl start nombre_servicio.service
sudo systemctl stop nombre_servicio.service
sudo systemctl restart nombre_servicio.service

Esses padrões se repetem em praticamente qualquer serviço, desde Apache2, Nginx ou SSH , até serviços de banco de dados , serviços de impressão ou qualquer outra coisa que você possa imaginar.

Gerenciamento de serviços: iniciar, recarregar, parar e monitorar.

Em um ambiente real, você usará o systemctl para manter serviços essenciais funcionando sem problemas : servidores web, bancos de dados, serviços de rede, daemons de backup e assim por diante. O objetivo é minimizar o tempo de inatividade e implementar alterações de configuração com o menor impacto possível.

Para iniciar um serviço que deve estar ativo (por exemplo, o Apache), o comando típico seria:

sudo systemctl start apache2

Se o Apache já estiver em execução, você não notará nada de incomum; se ele foi interrompido, o daemon iniciará processos filhos e começará a processar as requisições. Sempre que tiver dúvidas sobre o que aconteceu, execute os seguintes comandos:

sudo systemctl status apache2

Ao alterar o arquivo de configuração principal ou um host virtual , geralmente você recarrega ou reinicia o serviço. Recarregar é uma opção mais suave:

sudo systemctl reload apache2

Isso permite que o serviço releia os arquivos de configuração sem interromper os processos em execução, de modo que os usuários praticamente não percebem nada. Se, por algum motivo, o serviço não suportar a recarga, você precisará:

sudo systemctl restart apache2

Em alguns casos, se o serviço estiver com mau funcionamento ou não responder, uma reinicialização completa libera recursos e remove processos zumbis . É uma das etapas de diagnóstico típicas antes de analisar os registros em detalhes .

Para interromper temporariamente um serviço devido à manutenção ou por não precisar dele por um tempo, basta:

sudo systemctl stop apache2

Isso não impede que ele reinicie na próxima reinicialização, caso esteja ativado. Se você quiser que ele desapareça completamente até segunda ordem, combine `stop` com `disable` ou `mask`, dependendo do nível de "proibição" que deseja aplicar.

Após qualquer operação sensível, é altamente recomendável verificar o status do serviço e seus registros mais recentes com:

sudo systemctl status nombre_servicio

E, se precisar de mais contexto, com o journalctl , por exemplo:

sudo journalctl -u nombre_servicio

Solução de problemas comuns com o systemctl

Quando algo dá errado ao iniciar um serviço com o systemctl , você normalmente verá mensagens como "Job for X failed" ou status " failed " na saída do status. As etapas padrão de solução de problemas geralmente são:

1. Verifique o estado detalhado da unidade:

sudo systemctl status nombre_servicio

Ali você poderá verificar se o serviço não está iniciando devido a uma falha de comando, um tempo limite excedido, problemas de permissão, um arquivo ausente, etc. Observe linhas como "Main PID exited" e as mensagens de erro reais do aplicativo.

2. Analise os registros completos com o journalctl:

sudo journalctl -u nombre_servicio

Isso fornece o histórico de registros gerado pela unidade, o que é muito útil caso o serviço "pare de funcionar" logo após a inicialização.

3. Verifique se está ativado quando você espera que o sistema inicialize:

sudo systemctl is-enabled nombre_servicio

Se aparecer como desativado, basta:

sudo systemctl enable nombre_servicio

4. Verifique as permissões e o usuário.Alguns serviços precisam ser executados como um usuário específico ou acessar caminhos específicos. Se o arquivo de unidade especificar um User= o Group= incorreto, ou a rota em ExecStart= Se não existir ou não for acessível, o serviço pode parar de funcionar instantaneamente.

5. Se você modificou manualmente o arquivo de unidade, lembre-se sempre de recarregar a configuração do systemd com:

sudo systemctl daemon-reload

Esquecer esta etapa é um erro clássico: você faz as alterações, reinicia o serviço e ainda vê o comportamento antigo porque o systemd ainda não leu o novo arquivo.

Ao manter essa rotina de verificações e revisar periodicamente o status das unidades principais, fica muito mais fácil manter um sistema Linux estável e previsível.

Como você pode ver, o systemctl se torna o canivete suíço para gerenciar serviços, unidades e estados do sistema em qualquer distribuição moderna com systemd: ele permite iniciar e parar daemons com precisão, controlar o que inicia na inicialização do sistema, investigar erros em detalhes consideráveis, ajustar configurações sem sobrescrever arquivos do sistema e alternar de um modo gráfico para um modo de recuperação em questão de segundos. Dominar esses comandos não só facilita muito o gerenciamento de servidores ou desktops Linux, como também lhe dá muito mais confiança ao solucionar problemas sérios em produção, porque você sabe exatamente o que está sendo executado, por que e como parar ou modificar com segurança.