De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
Colaboração: Rubens Queiroz de Almeida
Data de Publicação: 19 de junho de 2026
O systemctl é a ferramenta de linha de comando definitiva para controlar o systemd, que é o sistema de inicialização e gerenciamento de serviços (daemons) padrão da esmagadora maioria das distribuições Linux modernas (como Ubuntu, Debian, Fedora, Arch Linux e RHEL).
Se o Linux fosse uma empresa, o systemd seria o gerente geral, e o systemctl seria o rádio ou o painel de controle que você usa para dar ordens a esse gerente.
Para entender a importância do systemctl, precisamos olhar para o passado do Linux. Antigamente, o gerenciamento do sistema era feito por um ecossistema chamado SysVinit (System V Init).
No SysVinit, os serviços eram controlados por scripts complexos em Bash guardados dentro da pasta /etc/init.d/. Para ligar um serviço, você usava comandos antigos como sudo service apache2 start ou rodava o script diretamente: /etc/init.d/apache2 start.
/etc/init.d/ era escrito por desenvolvedores diferentes, sem um padrão visual de erros ou logs.
Criado para modernizar o ecossistema, o systemd substituiu o SysVinit. Ele trouxe uma arquitetura focada em paralelismo agressivo (ele liga o máximo de serviços que conseguir ao mesmo tempo usando sockets) e padronizou tudo através de arquivos de texto simples chamados Units (Unidades), geralmente com a extensão .service. O systemctl nasceu junto como a única ferramenta necessária para gerenciar todo esse novo motor.
.service dizendo exatamente: "Só ligue este app DEPOIS que o banco de dados e a rede estiverem funcionando".
systemd agrupa os processos de um serviço usando Control Groups (cgroups). Se um serviço web começar a vazar memória ou criar processos filhos infinitos, você consegue derrubar o grupo inteiro com um único comando, sem deixar "processos zumbis" poluindo a memória.
systemd pode ser configurado para reerguê-lo automaticamente em milissegundos.
No jargão do systemctl, quase tudo é uma "Unit" (Unidade). O tipo mais comum de Unit é o .service (Serviço).
Um arquivo .service é apenas um arquivo de texto de configuração que diz ao Linux como rodar um programa em segundo plano. Por exemplo, o arquivo /etc/systemd/system/ollama.service tem uma estrutura parecida com esta:
ini [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always [Install] WantedBy=default.target
Quando você digita systemctl start ollama, a ferramenta lê esse arquivo de configuração, sabe que deve rodar o executável /usr/local/bin/ollama serve usando o usuário ollama, e que se ele quebrar, deve dar um Restart=always (reiniciar sempre).
Para a maioria dos comandos de controle (iniciar, parar, reiniciar), você precisará usar o sudo. Para comandos de consulta (status, listagem), o usuário comum basta.
Esses comandos alteram o estado do serviço agora, na memória RAM, mas não afetam o que acontece se o computador for reiniciado.
$ sudo systemctl start nome_do_serviço
$ sudo systemctl stop nome_do_serviço
$ sudo systemctl restart nome_do_serviço
$ sudo systemctl reload nome_do_serviço
Esses comandos determinam se o serviço deve ou não ligar sozinho automaticamente assim que o computador/servidor for ligado.
$ sudo systemctl enable nome_do_serviço
$ sudo systemctl disable nome_do_serviço
O Comando Combo (--now): Se você quiser ativar no boot e iniciar o serviço ao mesmo tempo com uma única linha, use o argumento --now:
$ sudo systemctl enable --now nome_do_serviço
$ systemctl status nome_do_serviço
active ou inactive (ótimo para usar em scripts automatizados).
$ systemctl is-active nome_do_serviço
enabled ou disabled.
$ systemctl is-enabled nome_do_serviço
Se você alterou um arquivo de configuração interna do systemd (como fizemos nos arquivos .conf de override do Ollama), você precisa avisar o gerenciador para reler os arquivos do disco:
$ sudo systemctl daemon-reload
systemctl list-units --type=service
mask impede permanentemente que um serviço seja iniciado, mesmo que outro programa tente forçar a inicialização dele. Ele cria um link simbólico para o vazio (/dev/null).
$ sudo systemctl mask nome_do_serviço
$ sudo systemctl unmask nome_do_serviço
| O que você quer fazer? | Comando systemctl |
|---|---|
| Ligar um app agora | sudo systemctl start [app] |
| Desligar um app agora | sudo systemctl stop [app] |
| Reiniciar um app | sudo systemctl restart [app] |
| Fazer o app ligar junto com o Linux | sudo systemctl enable [app] |
| Impedir o app de ligar no boot | sudo systemctl disable [app] |
| Investigar por que o app deu erro | systemctl status [app] |
Aplicar mudanças após alterar um arquivo .service |
sudo systemctl daemon-reload |