Comando journalctl: uso, logs por serviço e limpeza do tamanho do journal

O comando journalctl é a ferramenta para selecionar e ler, no journal do systemd, os logs deixados pelos serviços e pelo kernel. No Linux com systemd, o systemd-journald reúne esses logs no journal. Ao ler logs por serviço, horário e prioridade em um servidor AlmaLinux 9 e em um servidor Debian 12, uma conta comum via apenas os próprios logs, e um servidor que mantém o journal na memória não conseguia escolher uma inicialização anterior.

A saída abaixo vem dos dois servidores. Nomes de host, contas, IDs de boot, os números de processo do servidor AlmaLinux e a versão do pacote systemd foram trocados por valores de exemplo, e os dois servidores mostraram os horários em UTC.

1️⃣ Como usar o comando journalctl e ver os logs recentes

Se você executar journalctl sem opções, o journal abre no less a partir da linha mais antiga; por isso, para ver os logs recentes, defina o número de linhas com -n. Se omitir o número depois de -n, aparecem 10 linhas.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Cada linha é formada pelo horário, pelo nome do host, pelo programa que gravou o log com o número do processo e pela mensagem. Com -r, a ordem se inverte e a linha mais recente vai para o topo. No log do crond do servidor AlmaLinux, a linha CMDEND gravada por último ficou no topo.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f não termina depois da última linha e continua mostrando as novas linhas que chegam. No servidor Debian 12, a última linha do logger ficou na tela com -q e -t myapp, e mais duas linhas foram gravadas com o logger. As duas linhas apareceram logo abaixo.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f só para quando você pressiona Ctrl+C, então use-o para acompanhar o log enquanto um serviço reinicia.

No less, linhas mais largas que a tela são cortadas à direita, e a parte cortada é vista com as setas. A saída enviada para um pipe ou arquivo não passa pelo less. Para mostrar direto no terminal sem o less, adicione --no-pager.

2️⃣ Logs do journalctl por serviço

As linhas recentes misturam logs de vários serviços; para ver o log de um só serviço, informe o nome da unidade com -u. O .service no fim do nome da unidade pode ser omitido.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

Se você escrever -u duas vezes, os logs dos dois serviços saem misturados em ordem de horário. Ao selecionar crond e nginx juntos de 08:00 a 08:15 de 18 de outubro no servidor AlmaLinux, depois de quatro linhas do crond às 08:01 vieram duas linhas de nginx reload às 08:12.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status mostra só as últimas 10 linhas de log abaixo do status do serviço, então confira os logs anteriores com journalctl -u. Logo depois de executar systemctl restart em um serviço, rode journalctl -u para conferir o log de inicialização.

Logs que scripts ou tarefas do cron gravaram com o logger são encontrados pela etiqueta (identificador), não por uma unidade. Depois de -t, escreva o mesmo nome usado no -t do logger.

logger -t myapp 'journalctl test message'

No servidor Debian 12, o logger não mostrou nada na tela, e as linhas gravadas foram encontradas com -t myapp.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g mantém só as linhas cuja mensagem contém um texto específico. Se você escrever o texto todo em minúsculas, maiúsculas e minúsculas não são diferenciadas.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n conta as linhas antes de o -g filtrar, por isso, das duas últimas linhas do crond, só sobrou a que continha anacron.

3️⃣ Logs por intervalo de tempo e por inicialização

--since e --until definem o início e o fim do intervalo de tempo exibido. Se houver um espaço entre a data e a hora, coloque o valor entre aspas simples.

No servidor AlmaLinux, as últimas 2 horas começaram nas linhas do crond gravadas às 06:01; abaixo estão as quatro primeiras.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b mantém só os logs desde a inicialização atual. Para descobrir por que um servidor reiniciou, confira primeiro na lista de inicializações se ainda há logs da inicialização anterior.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots mostra, para cada inicialização mantida no journal, o número, o ID de boot e os horários da primeira e da última linha.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

O servidor AlmaLinux não guarda o journal em disco, por isso tinha só um registro de inicialização. Assim, -b -1 para a inicialização anterior só deixou um aviso e terminou.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Os logs de uma inicialização anterior só podem ser lidos com -b -1 em servidores que salvam o journal em disco (/var/log/journal).

4️⃣ Logs de erro e logs do kernel com journalctl

-p seleciona linhas pela prioridade do log. Se você informar um nível, aparecem esse nível e todos os mais importantes, e o nível pode ser escrito por nome ou por número.

Depois de gravar uma linha de nível err com o logger e selecionar com -p err, a linha de nível notice com a mesma etiqueta (journalctl test message) saiu e só a linha err ficou.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

Ligar dois níveis com dois pontos mostra só esse intervalo. Com warning..err, ficam só os níveis de aviso e de erro.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k mantém só as mensagens do kernel e mostra só as linhas desde a inicialização atual.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

As três últimas linhas de -k no servidor AlmaLinux eram todas do systemd-rc-local-generator. Essas linhas são mensagens gravadas no buffer de log do kernel, então são salvas com _TRANSPORT igual a kernel e também aparecem com -k.

5️⃣ Formatos de saída do journalctl

-o muda o formato de cada linha. O padrão short é quase igual a um arquivo syslog, e short-iso converte o horário para o formato ISO 8601 com o fuso horário. Ao trocar para short-iso no servidor AlmaLinux, +0000 foi acrescentado ao fim do horário.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat tira o horário e o nome do host e mostra só a mensagem; use-o ao passar mensagens para o grep ou outro programa.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json e json-pretty mostram os campos salvos no journal como nomes e valores. Ao escolher campos com --output-fields, os campos de cursor, horário e ID de boot sempre vêm junto. Mesmo escolhendo só quatro campos no servidor Debian 12, __CURSOR, _BOOT_ID e dois campos de horário apareceram junto.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Local do journal e limpeza do tamanho

Se o journal fica na memória ou em disco é decidido pelo valor Storage= do journald.conf. O padrão auto salva em disco se a pasta /var/log/journal existir e na memória (/run/log/journal) se não existir.

O servidor AlmaLinux não tinha a pasta /var/log/journal, então o journal ficava só em /run/log/journal.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

O servidor Debian 12 tinha as duas pastas, e o journal ia se acumulando em disco.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Para manter os logs depois de reiniciar, mude Storage= no journald.conf para persistent e reinicie o systemd-journald. Segundo o manual oficial, a pasta /var/log/journal é criada automaticamente quando necessário. As configurações não foram alteradas para este artigo.

Um journal salvo em disco é como a caixa-preta de um avião, que se retira e se lê depois de um incidente.

--disk-usage mostra o tamanho somado dos arquivos do journal arquivados e dos que estão em uso. Em uma conta comum do servidor Debian 12, com o aviso [Hint] do topo escondido por -q, o resultado foi uma única linha: 6.6M.

journalctl -q --disk-usage

Archived and active journals take up 6.6M in the file system.

O tamanho máximo do journal salvo em disco é definido com SystemMaxUse=. Sem valor, o limite é 10% do tamanho do sistema de arquivos (até 4G), e no journald.conf do servidor Debian 12 estava escrito 50M.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Para reduzir logo os journals antigos, defina o tamanho a manter com --vacuum-size ou o período a manter com --vacuum-time. Os dois comandos apagam arquivos do journal, por isso não foram executados neste artigo.

journalctl --vacuum-size=200M

--vacuum-size=200M apaga os arquivos do journal arquivados, começando pelos mais antigos, até o tamanho total ficar abaixo de 200M.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks apaga os arquivos arquivados que só contêm linhas com mais de 2 semanas.

vacuum apaga só os arquivos arquivados e mantém os que estão em uso; por isso, mesmo depois de executado, o número do --disk-usage pode não cair até o tamanho definido.

Os logs de texto em /var/log são gravados pelo rsyslog, que funciona separado do journald. Por isso os dois logs são lidos e gerenciados de forma diferente.

7️⃣ Permissões de leitura e opções do comando journalctl

🔲 Permissões de leitura

Ao executar journalctl com uma conta que não é root, um texto [Hint] aparece no topo e só ficam visíveis os logs gravados por essa conta. Ao procurar os logs do nginx com uma conta comum no servidor Debian 12, depois do aviso só apareceu [-- No entries --].

journalctl -u nginx -n 5

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.
-- No entries --

Pelo id -nG, essa conta pertencia a um só grupo e não estava nos grupos adm nem systemd-journal citados no aviso.

id -nG

user

O manual oficial explica que contas dos grupos systemd-journal, adm e wheel podem ler todo o journal. adm e wheel trazem outras permissões definidas pela distribuição, e wheel muitas vezes permite também tarefas de administração; por isso, para uma conta que só lê logs, o grupo certo é systemd-journal.

usermod -aG systemd-journal user

O comando usermod que adiciona o grupo não foi executado neste artigo. Depois de adicionar o grupo, entre de novo e confira os grupos com id -nG. Uma conta com permissão de administrador também vê todos os logs ao executar sudo journalctl.

O texto [Hint] é escondido com -q. Mesmo com -q, porém, os logs visíveis continuam sendo só as linhas gravadas por essa conta. --user lê o journal de usuário dessa conta e só funciona em servidores que salvam o journal em disco. No servidor Debian 12, que mantém o journal em disco, apareceram as linhas do systemd e do logger dessa conta.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 Opções do comando journalctl

📌 Principais opções: resultados deste artigo

📎 Outras opções: segundo o manual oficial

🔲 Simulador do comando journalctl

No simulador abaixo, você pode digitar os comandos para conferir logs recentes, logs por serviço, intervalos de tempo, prioridades e formatos de saída.

🔢 FAQ & conteúdo recomendado

🧭 Comandos de informação · configuração do sistema: conteúdo recomendado 8 artigos · 2 referências

🗂️ Comandos de informação · configuração do sistema

▸📂 Informação do sistema4

📄 Informações de CPU · RAM · disco · SO 📄 uname · versão do kernel 📄 Comando free 📄 Comando uptime

▸📂 Configuração2

📄 Comando timedatectl 📄 Comando localectl

▸📂 Logs2

📄 logrotate 📄 Comando journalctl

▸🪐 Referências2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Informação do sistema

Como verificar a CPU no Linux: comandos para RAM, disco e informações do SO

No Linux, o número de núcleos da CPU aparece na hora com uma linha: [nproc].

Ver post →Conteúdo atual

Linux · Informação do sistema

Comandos para verificar a versão do kernel Linux e como verificar a versão da distribuição

Ao administrar Linux, às vezes é preciso verificar a versão do kernel do Linux e a versão da distribuição.

Ver post →Conteúdo atual

Linux · Informação do sistema

Comando free no Linux: verificar o estado da memória

O comando free do Linux mostra o uso de memória e a memória livre do servidor, lendo as informações de memória de /proc/meminfo.

Ver post →Conteúdo atual

Linux · Informação do sistema

Comando uptime do Linux (tempo de atividade do servidor & carga média de 1, 5 e 15 minutos)

O comando uptime do Linux mostra a carga média do sistema e há quanto tempo o servidor está ligado.

Ver post →Conteúdo atual

Linux · Configuração

Sincronizar a hora do servidor Linux: timedatectl (CentOS 7 ou superior)

No Linux é preciso ajustar data e hora porque, se a hora estiver errada com o servidor em funcionamento, os horários dos dados do BD, dos logs e dos acessos ao servidor web podem não bater.

Ver post →Conteúdo atual

Linux · Configuração

[Linux] Comando localectl

A partir do CentOS 7, muitos comandos são oferecidos de forma integrada.

Ver post →Conteúdo atual

Linux · Logs

Logrotate no Linux: conceito e configuração

O Logrotate do Linux, como a expressão "girar os logs" sugere, é a junção de log e rotate.

Ver post →Conteúdo atual

Linux · Logs

Comando journalctl: uso, logs por serviço e limpeza do tamanho do journal

O comando journalctl é a ferramenta para selecionar e ler, no journal do systemd, os logs deixados pelos serviços e pelo kernel, e no Linux com systemd o systemd-journald reúne esses logs no journal.

Ver post →Conteúdo atual

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ Aviso de afiliados
O conteúdo deste site contém links de afiliados. Quando um visitante compra um produto ou serviço por meio de um desses links, o site recebe uma comissão do vendedor. O valor que o comprador paga ^{(em promoções, ele diminui ↓)} não aumenta por causa disso. Preços, descontos e informações de estoque valem para o momento em que o texto foi escrito e podem ter mudado, por isso confirme com o vendedor antes de comprar. Os produtos são escolhidos e avaliados por critérios próprios, e o recebimento de comissão não influencia a ordem de apresentação nem o conteúdo das avaliações.