apt-daily-upgrade rodando sozinho: por que timers automáticos precisam entrar na investigação de incidentes

Nem toda mudança em um servidor veio de alguém conectado por SSH.

Em Ubuntu moderno, vários serviços são executados automaticamente por timers do systemd.

Durante uma investigação real, a timeline mostrava atividades como:

1
2
3
4
5
apt-daily.timer
apt-daily-upgrade.timer
logrotate.timer
snap.certbot.renew.timer
systemd-tmpfiles-clean.timer

Em outra janela operacional, apt-daily-upgrade.service terminou poucos segundos depois de serviços importantes do host terem sido reiniciados.

Isso é suficiente para colocar o timer na investigação.

Não é suficiente para declarar:

apt-daily-upgrade causou o incidente.

Essa diferença é o ponto deste artigo.

Primeiro: descubra quais timers existem #

Um comando simples:

1
systemctl list-timers --all --no-pager

Num host real, a saída mostrava, entre outros:

1
2
3
4
5
6
7
apt-daily.timer
apt-daily-upgrade.timer
dpkg-db-backup.timer
logrotate.timer
snap.certbot.renew.timer
man-db.timer
systemd-tmpfiles-clean.timer

A coluna mais interessante durante incidente é a combinação:

1
2
3
4
LAST
NEXT
UNIT
ACTIVATES

Ela permite reconstruir o que deveria ter disparado perto do horário observado.

Timer e service são duas peças diferentes #

apt-daily-upgrade.timer agenda.

apt-daily-upgrade.service executa.

Então eu consulto os dois:

1
2
systemctl status apt-daily-upgrade.timer --no-pager
systemctl status apt-daily-upgrade.service --no-pager

E o journal:

1
2
3
4
journalctl -u apt-daily-upgrade.service \
  --since '2026-01-01 00:00:00' \
  --until '2026-01-01 01:00:00' \
  --no-pager

Use a janela real do incidente, não o exemplo acima.

A timeline é mais útil que o status atual #

Se eu olhar apenas:

1
systemctl status apt-daily-upgrade.service

horas depois, posso ver apenas inactive (dead).

Isso não diz se o serviço executou às 03:17.

O journal diz.

Também vale:

1
2
journalctl --since '...' --until '...' \
  | grep -Ei 'apt|dpkg|unattended|needrestart|systemd'

A ideia é correlacionar eventos, não caçar uma palavra isolada.

`apt-daily` e `apt-daily-upgrade` não fazem exatamente a mesma coisa #

De forma operacional:

apt-daily está ligado a atualização/download periódico de metadados e pacotes;
apt-daily-upgrade está ligado às atividades automáticas de upgrade/clean quando configuradas.

A configuração real depende de:

APT periodic;
unattended-upgrades;
políticas da distribuição;
overrides locais;
timers habilitados.

Então eu verifico também:

1
2
grep -R "APT::Periodic\|Unattended-Upgrade" \
  /etc/apt/apt.conf.d/ 2>/dev/null

Um caso real mostrou execução do upgrade automático na mesma janela operacional #

No journal recuperado, apt-daily-upgrade.service terminou com sucesso e registrou consumo de CPU/memória.

Naquela mesma janela havia atividade de serviços importantes do host.

O que posso afirmar:

1
2
FACT: o timer/service executou naquele horário.
FACT: outros serviços tiveram eventos próximos no journal.

O que não posso afirmar sem evidência adicional:

1
HYPOTHESIS: o apt causou a queda/restart.

Para promover a hipótese a causa, eu procuraria algo como:

pacote alterado diretamente relacionado ao serviço;
needrestart reiniciando unidade;
maintainer script executando restart;
timestamp exato consistente;
log do serviço mostrando impacto da atualização;
ausência de causa concorrente melhor sustentada.

Ver o que o APT realmente alterou #

Fontes úteis:

1
2
less /var/log/apt/history.log
less /var/log/apt/term.log

Também:

1
2
zgrep -hE 'Start-Date|Commandline|Upgrade:|Install:|Remove:' \
  /var/log/apt/history.log*

E logs do unattended-upgrades quando presentes:

1
ls -lah /var/log/unattended-upgrades/

Pergunta principal:

houve mudança de pacote relevante naquela janela?

`needrestart` pode ser a ponte entre pacote e serviço #

Uma atualização de biblioteca pode não reiniciar aplicação por si só.

Ferramentas/políticas de restart podem detectar processos usando bibliotecas antigas e sugerir ou executar ações conforme configuração.

Por isso eu procuro:

1
journalctl --since '...' --until '...' | grep -i needrestart

E reviso a política instalada.

Mas novamente: presença do needrestart não prova que ele reiniciou o serviço investigado.

Outros timers também entram na mesma lógica #

No snapshot real havia Certbot, logrotate, limpeza de temporários e atualização de índices.

Dependendo do incidente, algum deles pode ser mais relevante que APT.

Certbot #

1
2
systemctl status snap.certbot.renew.timer
journalctl -u snap.certbot.renew.service

Logrotate #

1
2
systemctl status logrotate.timer
journalctl -u logrotate.service

tmpfiles #

1
2
systemctl status systemd-tmpfiles-clean.timer
journalctl -u systemd-tmpfiles-clean.service

A pergunta é sempre:

algum job automático tocou no mesmo recurso ou serviço no intervalo?

Cron continua existindo #

Timer systemd não substitui automaticamente todos os crons do ambiente.

Então também:

1
2
3
crontab -l
sudo crontab -l
ls -lah /etc/cron.d /etc/cron.daily /etc/cron.hourly

Em frotas heterogêneas, a mesma função pode estar em timer num host e cron em outro.

Como eu monto uma timeline rápida #

Exemplo:

1
2
3
4
5
START='2026-01-01 02:45:00'
END='2026-01-01 03:30:00'

journalctl --since "$START" --until "$END" \
  --no-pager -o short-iso

Depois eu separo:

1
2
3
4
5
6
7
8
serviço afetado
timers automáticos
apt/dpkg
kernel/OOM
reboots
sudo/sessions
Docker
rede/storage

O objetivo é montar causalidade temporal antes de formular RCA.

Não desabilite timer só porque ele apareceu perto do incidente #

Outro erro comum é:

1
systemctl disable --now apt-daily-upgrade.timer

imediatamente após vê-lo na timeline.

Isso é uma mudança operacional com impacto em patching.

Pode ser apropriado em ambientes onde updates automáticos são deliberadamente proibidos e geridos por janela controlada.

Mas a decisão precisa ser de política, não reflexo de suspeita.

Primeiro descubra:

o que executou;
o que mudou;
se houve impacto;
qual é a política esperada do host.

O que a fonte sustenta #

Uma coleta real de Ubuntu 24.04 mostra timers ativos para APT, Certbot, logrotate e outras rotinas, com timestamps de última/próxima execução.

Outro journal real mostra apt-daily-upgrade.service concluindo na mesma janela em que havia eventos de serviços do host.

Essas evidências justificam incluir tarefas automáticas na timeline.

Elas não são usadas para afirmar que APT foi a causa de uma queda específica.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
[ ] systemctl list-timers --all
[ ] capturar LAST/NEXT dos timers relevantes
[ ] journal da janela do incidente
[ ] apt history/term log
[ ] unattended-upgrades log
[ ] needrestart
[ ] cron root/usuário/sistema
[ ] pacote alterado relacionado ao serviço?
[ ] restart real registrado?
[ ] outras causas concorrentes?
[ ] política desejada de atualização automática?

O principal aprendizado #

Quando ninguém admite ter mexido no servidor, isso não significa que nada executou.

Systemd timers, cron e mecanismos de atualização automática são atores da timeline.

A forma correta de usá-los numa investigação é:

1
2
3
4
provar que executaram
→ provar o que fizeram
→ correlacionar com o serviço
→ só então discutir causalidade

Coincidência de horário é evidência para investigar.

Não é RCA.