Ubuntu Logs (journalctl)

Quando algo dá errado no Linux, a resposta quase sempre está nos logs: registros com data e hora do que cada programa fez. No Ubuntu, o systemd guarda tudo num lugar só, o journal, e o comando journalctl lê esse registro. Saber filtrar os logs é o que separa "o serviço não funciona" de "o serviço não funciona porque a linha 22 tem um erro de digitação".

Antes do comando: como funciona o journal

O systemd-journald é um serviço que recolhe mensagens de várias fontes:

• tudo o que os serviços escrevem na tela (a saída do echo de um script, por exemplo);
• mensagens do kernel (hardware, pendrive conectado, falta de memória);
• mensagens de login, sudo, cron e outros programas do sistema.

Cada linha guarda data, máquina, programa, PID e a mensagem. O journal fica em /var/log/journal/, num formato próprio que só o journalctl lê.

Quem pode ler

Usuários dos grupos adm ou systemd-journal leem o log inteiro, sem sudo. No Ubuntu, o primeiro usuário criado já está no adm. Confira:

$ groups
ana adm cdrom sudo dip plugdev users lpadmin          « "adm" está na lista

Fora desses grupos, você só vê as suas próprias mensagens, e o journalctl avisa:

$ journalctl
Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.

A forma mais simples: journalctl

$ journalctl

Sem opções, ele abre todo o log, do mais antigo para o mais novo, dentro do paginador less. São centenas de milhares de linhas, então quase nunca é o que você quer. Use as teclas:

A partir daqui, vamos sempre filtrar.

As últimas linhas: -n e -e

journalctl

O leitor de logs.

-n 5

De number: só as 5 linhas mais recentes.

$ journalctl -n 5
out 15 10:17:01 notebook CRON[32051]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
out 15 10:17:01 notebook CRON[32049]: pam_unix(cron:session): session closed for user root
out 15 10:20:44 notebook sudo[33410]:      ana : TTY=pts/0 ; PWD=/home/ana ; USER=root ; COMMAND=/usr/bin/apt update
out 15 10:20:44 notebook sudo[33410]: pam_unix(sudo:session): session opened for user root(uid=0) by ana(uid=1000)
out 15 10:20:49 notebook sudo[33410]: pam_unix(sudo:session): session closed for user root

Cada linha tem quatro partes:

Para abrir o paginador já no fim, use -e (de end). -r (de reverse) inverte a ordem: mais novo primeiro.

Um serviço só: -u

O filtro mais usado. -u é de unit:

journalctl

O leitor.

-u cron

Só as mensagens do serviço cron.

-n 3

Só as 3 últimas.

$ journalctl -u cron -n 3
out 15 10:30:01 notebook CRON[37467]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
out 15 10:30:01 notebook CRON[37469]: (root) CMD (if [ -x /etc/init.d/anacron ] && ! [ -d /run/systemd/system ]; then exec /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
out 15 10:30:01 notebook CRON[37467]: pam_unix(cron:session): session closed for user root

Você pode repetir o -u para ver dois serviços juntos: journalctl -u nginx -u php8.4-fpm.

Ao vivo: -f

-f (de follow, "seguir") mostra as últimas linhas e fica esperando novas. Ideal para ver o que acontece enquanto você testa algo em outra janela:

$ journalctl -u ssh -f
out 15 10:41:02 servidor sshd-session[6610]: Accepted publickey for ana from 192.168.0.10 port 51234 ssh2: ED25519 SHA256:k3J…
out 15 10:41:02 servidor sshd-session[6610]: pam_unix(sshd:session): session opened for user ana(uid=1000) by ana(uid=0)
^C                                                      « Ctrl+C para sair

Por boot: -b

O journal separa as mensagens por boot (cada vez que o computador ligou). Isso é precioso quando o problema foi "antes de reiniciar".

$ journalctl --list-boots
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 aa184955aef34b8890f1ad575241b32a Wed 2026-10-14 19:09:12 -03 Wed 2026-10-14 20:21:40 -03
 -1 668d4e261c4b45bfae8192400148225d Thu 2026-10-15 07:06:14 -03 Thu 2026-10-15 07:43:07 -03   « o anterior
  0 a24bc39a819e4383bb915613ee653a2f Thu 2026-10-15 07:43:43 -03 Thu 2026-10-15 10:30:56 -03   « o atual

Por gravidade: -p

Cada mensagem tem uma prioridade, de 0 (o pior) a 7 (detalhe de depuração):

-p err mostra erros e tudo mais grave (err, crit, alert, emerg). Combinado com -b, vira um "checkup" rápido do boot atual:

$ journalctl -b -p err
out 15 10:25:13 notebook adduser[35808]: Only root may add a user or group to the system.
out 15 10:29:40 notebook kernel: usb 1-4: device descriptor read/64, error -71

Para uma faixa, use dois pontos: -p warning..err mostra de "aviso" até "erro". Linhas de erro aparecem em vermelho e avisos em amarelo no seu terminal.

Por horário: --since e --until

journalctl

O leitor.

-u ssh

Só o SSH.

--since "1 hour ago"

Desde uma hora atrás. Entre aspas, por causa dos espaços.

$ journalctl --since "08:00" --until "09:00"
$ journalctl -u ssh --since yesterday
$ journalctl --since ontem
Failed to parse timestamp: ontem              « as palavras são sempre em inglês

Por palavra: -g

-g (de grep) filtra pelo texto da mensagem, ignorando maiúsculas quando o padrão está todo em minúsculas:

$ journalctl -b -g "usb"
out 15 07:44:01 notebook kernel: usb 1-4: new high-speed USB device number 5 using xhci_hcd
out 15 07:44:01 notebook kernel: usb-storage 1-4:1.0: USB Mass Storage device detected

A alternativa clássica é passar para o grep: journalctl -b | grep -i usb. O resultado é parecido; o -g é mais rápido em logs grandes.

Combinando filtros

Os filtros se somam. Esta é a pergunta típica de quem administra um servidor:

$ journalctl -u ssh --since today -g "Failed password"
out 15 03:12:44 servidor sshd-session[2210]: Failed password for root from 203.0.113.50 port 40112 ssh2      « tentativas de invasão
out 15 03:12:47 servidor sshd-session[2210]: Failed password for root from 203.0.113.50 port 40112 ssh2

"Quem tentou entrar no servidor hoje e errou a senha?" Esse é o tipo de investigação da página Segurança do Servidor.

Formatos de saída: -o

$ journalctl -u cron -n 1 -o short-iso
2026-10-15T10:30:01-03:00 notebook CRON[37467]: pam_unix(cron:session): session closed for user root

Cenário completo: o serviço não sobe

A Ana editou o site no servidor e reiniciou o nginx. Deu errado. Veja como investigar, do sintoma até a causa.

1. O sintoma.

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

   A mensagem já diz onde olhar. Vamos seguir a dica.

2. O log do serviço, com explicações.

   journalctl

   O leitor.

   -x

   Acrescenta explicações (linhas com ░░) a mensagens conhecidas.

   -e

   Pula para o fim: as mensagens mais recentes.

   -u nginx

   Só o nginx.

   $ journalctl -xeu nginx
   out 15 10:52:10 servidor systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...
   out 15 10:52:10 servidor nginx[6120]: 2026/10/15 10:52:10 [emerg] 6120#6120: unknown directive "servr_name" in /etc/nginx/sites-enabled/default:22   « a causa
   out 15 10:52:10 servidor nginx[6120]: nginx: configuration file /etc/nginx/nginx.conf test failed
   out 15 10:52:10 servidor systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
   ░░ Subject: Unit process exited
   ░░ Defined-By: systemd
   ░░
   ░░ An ExecStartPre= process belonging to unit nginx.service has exited.
   ░░
   ░░ The process' exit code is 'exited' and its exit status is 1.
   out 15 10:52:10 servidor systemd[1]: nginx.service: Failed with result 'exit-code'.
   out 15 10:52:10 servidor systemd[1]: Failed to start nginx.service - A high performance web server and a reverse proxy server.

   Leia de baixo para cima até achar a primeira mensagem do próprio programa (não do systemd). Aqui: [emerg] unknown directive "servr_name", ou seja, "diretiva desconhecida" no arquivo default, linha 22. É um erro de digitação: o certo é server_name.

3. Confirme. Muitos serviços têm um modo de testar a configuração. O nginx usa -t:

   $ sudo nginx -t
   nginx: [emerg] unknown directive "servr_name" in /etc/nginx/sites-enabled/default:22
   nginx: configuration file /etc/nginx/nginx.conf test failed

4. Corrija e teste de novo.

   $ sudo nano +22 /etc/nginx/sites-enabled/default     « abre o nano direto na linha 22
   $ sudo nginx -t
   nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
   nginx: configuration file /etc/nginx/nginx.conf test is successful

5. Reinicie e confira.

   $ sudo systemctl restart nginx
   $ systemctl is-active nginx
   active

Outras causas comuns e como aparecem no log

Espaço ocupado pelos logs

$ journalctl --disk-usage
Archived and active journals take up 535.8M in the file system.

O journal se limita sozinho (por padrão, até 10% do disco, com teto de 4 GB). Para liberar espaço agora:

sudo journalctl

Como administrador.

--vacuum-time=2weeks

"Aspira" (apaga) arquivos de log com mais de 2 semanas.

$ sudo journalctl --vacuum-time=2weeks
$ sudo journalctl --vacuum-size=200M       # ou: deixe no máximo 200 MB

Para mudar o limite de forma permanente, crie /etc/systemd/journald.conf.d/tamanho.conf com [Journal] e SystemMaxUse=500M, e rode sudo systemctl restart systemd-journald.

Formas diferentes de ver logs

Os arquivos em /var/log

Arquivos terminados em .1 e .2.gz são versões antigas, "rotacionadas". Para ler os .gz sem descompactar, use zcat ou zgrep.

Quando não funciona

$ journalctl -u apache
-- No entries --
$ echo $?
0

$ journalctl --since ontem
Failed to parse timestamp: ontem

$ dmesg
dmesg: leitura de buffer de kernel falhou: Operação não permitida

Referência de opções

Exercícios

Resumo

• O journal guarda os logs de serviços, kernel e logins; quem está no grupo adm lê tudo sem sudo.
• Filtros: -u serviço, -b boot, -p gravidade, --since horário, -g texto. Eles se somam.
• -f acompanha ao vivo; -n e -e mostram o fim.
• Serviço não sobe: journalctl -xeu nome, leia de baixo para cima até a mensagem do programa, teste a configuração, corrija, reinicie.
• --disk-usage mostra o espaço; --vacuum-time limpa (sem volta).