Ubuntu systemctl

Um serviço é um programa que roda o tempo todo em segundo plano, sem janela: o servidor SSH, o agendador de tarefas, o servidor web. Quem liga, desliga e vigia esses serviços no Ubuntu é o systemd, e você conversa com ele pelo comando systemctl.

Você vai aprender

O que são systemd, units e serviços.
Ler o systemctl status linha por linha.
A diferença entre start (agora) e enable (no próximo boot).
Listar serviços rodando e com falha.
Usar is-active e os códigos de saída em scripts.
Resolver "could not be found", "changed on disk" e serviços que não sobem.

Antes do comando: systemd e units

Quando o computador liga, o kernel inicia um programa: o systemd. Ele é o processo número 1 (PID 1) e é responsável por iniciar todo o resto, na ordem certa: rede, som, login, serviços. Depois, continua vigiando: se um serviço cai, ele pode reiniciá-lo.

Cada coisa que o systemd gerencia é uma unit ("unidade"), descrita num arquivo de texto. O tipo aparece no fim do nome:

Tipo	O que é	Exemplo
`.service`	Um programa (serviço)	`ssh.service`, `cron.service`
`.timer`	Um agendamento, como o cron	`apt-daily.timer`
`.socket`	Uma porta que liga o serviço quando alguém conecta	`ssh.socket`
`.mount`	Um disco montado	`home.mount`
`.target`	Um grupo de units, como um "estágio" do boot	`multi-user.target`, `graphical.target`

Quando você omite o tipo, o systemctl assume .service: systemctl status cron é o mesmo que systemctl status cron.service.

"Daemon"

Programas de serviço são chamados de daemons, e muitos têm nome terminado em d: sshd, systemd, journald. Veja o Glossário.

Ver o estado de um serviço: `status`

systemctl: O programa que conversa com o systemd.
status: A ação: mostrar o estado. Não precisa de sudo.
cron: O serviço (o agendador de tarefas, que vem em todo Ubuntu).

$ systemctl status cron
● cron.service - Regular background program processing daemon         « bolinha verde = rodando
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-10-15 08:00:07 -03; 2h 30min ago
 Invocation: 3621e95c278e44258095379b22b5828b
       Docs: man:cron(8)
   Main PID: 1961 (cron)
      Tasks: 1 (limit: 18339)
     Memory: 524K (peak: 2.8M)
        CPU: 44ms
     CGroup: /system.slice/cron.service
             └─1961 /usr/sbin/cron -f -P

out 15 08:00:07 notebook systemd[1]: Started cron.service - Regular background program processing daemon.
out 15 08:00:07 notebook cron[1961]: (CRON) INFO (pidfile fd = 3)
out 15 10:17:01 notebook CRON[32051]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)

A saída é longa, mas cada linha responde uma pergunta:

Linha	Pergunta que responde	No exemplo
Primeira linha	Que serviço é este?	O cron, com a descrição em inglês
`Loaded`	Onde está o arquivo da unit? Liga sozinho no boot?	Arquivo em `/usr/lib/systemd/system/`; `enabled` = liga no boot
`Active`	Está rodando agora? Desde quando?	`active (running)` há 2h30
`Main PID`	Qual é o processo principal?	PID 1961
`Tasks`, `Memory`, `CPU`	Quanto recurso está usando?	1 tarefa, 524 KB de memória, 44 ms de CPU no total
`CGroup`	Quais processos pertencem ao serviço?	Só o `/usr/sbin/cron`
Últimas linhas	O que o serviço registrou por último?	As 10 últimas linhas do log (veja journalctl)

A saída parou e não volta o prompt?

Quando a saída é maior que a tela, o systemctl abre um paginador (o less). Aperte Q para sair. Para não abrir o paginador, use --no-pager: systemctl status cron --no-pager.

Os estados possíveis

Símbolo	Active	Significado
● verde	`active (running)`	Rodando normalmente
● verde	`active (exited)`	Rodou uma vez e terminou com sucesso (normal para tarefas de configuração)
●	`activating`	Está ligando
○ branco	`inactive (dead)`	Parado
× vermelho	`failed`	Tentou rodar e deu erro

Um serviço com falha fica assim (repare no × e no código de saída do processo):

$ systemctl status meuapp
× meuapp.service - Meu aplicativo
     Loaded: loaded (/etc/systemd/system/meuapp.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Thu 2026-10-15 10:14:22 -03; 1min ago   « falhou
   Duration: 19ms
    Process: 5210 ExecStart=/usr/local/bin/meuapp (code=exited, status=2)             « saiu com erro 2
   Main PID: 5210 (code=exited, status=2)
        CPU: 10ms

O status diz que falhou. Para descobrir por quê, leia o log com journalctl -u meuapp. A página Logs (journalctl) mostra a investigação completa.

Ligar, desligar e reiniciar

Estas ações mudam o sistema, então precisam de sudo.

sudo: Como administrador.
systemctl: O programa.
restart: A ação: parar e iniciar de novo.
ssh: O serviço.

$ sudo systemctl restart ssh
[sudo: authenticate] Senha:
$ systemctl is-active ssh
active

Como quase todo comando, o systemctl restart não mostra nada quando dá certo. Por isso conferimos com is-active.

Ação	O que faz	Quando usar
`start`	Inicia	O serviço está parado
`stop`	Para	Você quer desligar agora
`restart`	Para e inicia	Depois de mudar a configuração
`reload`	Relê a configuração sem parar	Serviços que suportam (nginx, ssh); não derruba conexões
`reload-or-restart`	`reload` se der, senão `restart`	Quando você não sabe se o serviço suporta reload

Esqueceu o sudo?

No desktop, aparece uma janela pedindo a senha (é o polkit, que autoriza ações de administrador). Num terminal por SSH, ele pergunta a senha ali mesmo. Funciona, mas o hábito correto é usar sudo.

Ligar no boot: `enable` e `disable`

Esta é a confusão mais comum com o systemd: start liga agora, enable liga nos próximos boots. São coisas independentes.

Comando	Agora	Depois de reiniciar
`start`	Rodando	Parado (não volta)
`enable`	Não muda nada	Liga sozinho
`enable --now`	Rodando	Liga sozinho
`disable`	Não muda nada	Não liga
`disable --now`	Para	Não liga

sudo systemctl: Como administrador.
enable: Habilita no boot.
--now: E também inicia agora.
nginx: O serviço.

$ sudo systemctl enable --now nginx
Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx
Created symlink '/etc/systemd/system/multi-user.target.wants/nginx.service' → '/usr/lib/systemd/system/nginx.service'.
$ systemctl is-enabled nginx
enabled

O enable cria um link dentro de multi-user.target.wants. É assim que o systemd sabe o que ligar no boot: tudo que o estágio multi-user.target "quer" (wants). As linhas "SysV" aparecem em serviços que também têm um script antigo de inicialização; podem ser ignoradas.

Proibir de vez: `mask`

disable só tira do boot: outro programa ainda pode ligar o serviço. mask impede que ele seja ligado de qualquer forma, até você rodar unmask:

$ sudo systemctl mask cups
Created symlink '/etc/systemd/system/cups.service' → '/dev/null'.
$ sudo systemctl start cups
Failed to start cups.service: Unit cups.service is masked.
$ sudo systemctl unmask cups

O que o comando devolve: perguntas para scripts

Três ações respondem com uma palavra e um código de saída, perfeitas para scripts:

$ systemctl is-active cron
active
$ echo $?
0                                   « 0 = sim, está ativo
$ systemctl is-active cups
inactive
$ echo $?
3                                   « diferente de 0 = não
$ systemctl is-enabled cron
enabled
$ systemctl is-failed meuapp
failed

Num script, use direto no if, sem imprimir nada (--quiet):

#!/usr/bin/env bash
if ! systemctl is-active --quiet nginx; then
    echo "nginx caiu! Reiniciando..."
    sudo systemctl restart nginx
fi

Código de `systemctl status`	Significado
`0`	Ativo
`3`	Parado ou com falha
`4`	A unit não existe

Listar serviços

Os que estão rodando

systemctl list-units: Lista as units carregadas.
--type=service: Só serviços.
--state=running: Só os que estão rodando.

$ systemctl list-units --type=service --state=running
  UNIT                               LOAD   ACTIVE SUB     DESCRIPTION
  accounts-daemon.service            loaded active running Accounts Service
  avahi-daemon.service               loaded active running Avahi mDNS/DNS-SD Stack
  cron.service                       loaded active running Regular background program processing daemon
  cups.service                       loaded active running CUPS Scheduler
  dbus.service                       loaded active running D-Bus System Message Bus
  …

Os que falharam

Comece por aqui quando "algo está estranho" no sistema:

$ systemctl --failed
  UNIT            LOAD   ACTIVE SUB    DESCRIPTION
● vboxdrv.service loaded failed failed VirtualBox Linux kernel module     « algo para investigar

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

Nenhuma falha? Ele mostra 0 loaded units listed.

Os que ligam no boot

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

Os agendamentos (timers)

$ systemctl list-timers
NEXT                            LEFT LAST                          PASSED UNIT                ACTIVATES
Thu 2026-10-15 10:43:21 -03    13min Thu 2026-10-15 09:35:43 -03  54min ago fwupd-refresh.timer fwupd-refresh.service
Thu 2026-10-15 10:59:27 -03    29min Tue 2026-10-13 12:34:43 -03        - motd-news.timer     motd-news.service

Ver e ajustar o arquivo de um serviço

Ler: `cat`

$ systemctl cat cron
# /usr/lib/systemd/system/cron.service
[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
After=remote-fs.target nss-user-lookup.target

[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
Restart=on-failure
SyslogFacility=cron

[Install]
WantedBy=multi-user.target

A página Criar um Serviço explica cada linha.

Ajustar sem mexer no original: `edit`

Nunca edite os arquivos em /usr/lib/systemd/system/: uma atualização do pacote apaga sua mudança. O systemctl edit cria um arquivo de "ajuste" (override) separado, em /etc/systemd/system/cron.service.d/override.conf:

$ sudo systemctl edit cron

Abre um editor; escreva só o que quer mudar, entre as linhas de comentário indicadas, por exemplo:

[Service]
Restart=always
RestartSec=5

Ao salvar, o systemd recarrega a configuração sozinho. Depois, reinicie o serviço.

Mudou um arquivo à mão? `daemon-reload`

Se você editou ou criou um arquivo .service diretamente, avise o systemd:

$ sudo systemctl daemon-reload

Formas diferentes de fazer

Forma	Exemplo	Observação
`systemctl`	`sudo systemctl restart ssh`	A forma atual e completa
`service`	`sudo service ssh restart`	Comando antigo, ainda funciona; repare na ordem invertida
Interface gráfica	—	O Ubuntu não traz uma tela de serviços; o terminal é o caminho
Serviços do usuário	`systemctl --user status`	Serviços que rodam como você, sem sudo (ex.: o som, `pipewire`)

Desligar e reiniciar a máquina

$ systemctl reboot        # reiniciar
$ systemctl poweroff      # desligar
$ systemctl suspend       # suspender

No desktop, com você logado, não pedem senha. Num servidor por SSH, use sudo.

Quando não funciona

"could not be found"

$ systemctl status apache
Unit apache.service could not be found.
$ echo $?
4

O que aconteceu: não existe serviço com esse nome. O nome pode ser diferente do programa: no Ubuntu, o Apache é apache2 e o SSH é ssh (não sshd).

Como resolver: procure o nome certo:

$ systemctl list-unit-files | grep -i apache
apache2.service                              enabled         enabled

"changed on disk"

$ sudo systemctl restart meuapp
Warning: The unit file, source configuration file or drop-ins of meuapp.service changed on disk. Run 'systemctl daemon-reload' to reload units.

O que aconteceu: você editou o arquivo do serviço, mas o systemd ainda está usando a versão antiga.

Como resolver: sudo systemctl daemon-reload e depois sudo systemctl restart meuapp.

O serviço não sobe (failed)

$ sudo systemctl start meuapp
Job for meuapp.service failed because the control process exited with error code.
See "systemctl status meuapp.service" and "journalctl -xeu meuapp.service" for details.

O que aconteceu: o programa iniciou e saiu com erro. A causa está no log.

Como resolver: faça o que a própria mensagem sugere: journalctl -xeu meuapp. As causas mais comuns são erro no arquivo de configuração, porta já em uso e caminho errado no ExecStart. Siga o roteiro completo em Logs (journalctl).

Liguei o serviço, reiniciei e ele não voltou

O que aconteceu: você usou start, mas não enable.

Como resolver: sudo systemctl enable nome. Confira com systemctl is-enabled nome.

Referência

Comando	O que faz	sudo?
`systemctl status nome`	Estado detalhado + últimas linhas do log	Não
`systemctl start \| stop \| restart nome`	Liga, para, reinicia	Sim
`systemctl reload nome`	Relê a configuração sem parar	Sim
`systemctl enable \| disable [--now] nome`	Liga/desliga no boot (e agora, com `--now`)	Sim
`systemctl mask \| unmask nome`	Proíbe/libera totalmente	Sim
`systemctl is-active \| is-enabled \| is-failed nome`	Responde com uma palavra e código de saída	Não
`systemctl list-units --type=service --state=running`	Serviços rodando	Não
`systemctl --failed`	Units com falha	Não
`systemctl list-unit-files --state=enabled`	O que liga no boot	Não
`systemctl list-timers`	Agendamentos	Não
`systemctl cat nome`	Mostra o arquivo da unit	Não
`systemctl edit nome`	Cria um ajuste (override)	Sim
`systemctl daemon-reload`	Relê os arquivos de unit	Sim
`--no-pager`	Não abre o paginador	—
`--user`	Serviços do usuário	Não

Exercícios

1. Ligar agora e no boot

Complete para iniciar o ssh agora e fazê-lo ligar em todo boot, num comando só:

sudo systemctl enable ssh

2. Algo falhou?

Complete para listar todas as units com falha:

systemctl

3. Editei o arquivo do serviço

Você mudou /etc/systemd/system/meuapp.service à mão. Complete o comando que faz o systemd reler os arquivos:

sudo systemctl

4. Você rodou sudo systemctl start nginx e reiniciou o servidor. O nginx está rodando?

Sim, o start vale para sempre. Só se ele estiver enabled; o start vale só até desligar. Não, o systemd desliga todos os serviços no boot. Só se você rodar daemon-reload.

5. No systemctl status, o que significa Active: failed (Result: exit-code)?

O serviço está rodando normalmente. O serviço foi desabilitado no boot. O arquivo da unit não existe. O programa iniciou e saiu com um código de erro.

Resumo

systemd é o PID 1: inicia e vigia os serviços. Você fala com ele pelo systemctl.
status mostra tudo: se liga no boot (Loaded), se está rodando (Active), o PID e o log recente.
start/stop/restart valem agora; enable/disable valem para o boot; --now faz os dois.
is-active, is-enabled e is-failed devolvem códigos para scripts.
Falhou? systemctl --failed e journalctl -xeu nome. Editou o arquivo? daemon-reload.