<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Timers on /var/log/janio</title><link>https://devops.sarmento.org/tags/timers/</link><description>Recent content in Timers on /var/log/janio</description><generator>Hugo</generator><language>pt-BR</language><lastBuildDate>Sat, 11 Apr 2026 10:10:41 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/tags/timers/index.xml" rel="self" type="application/rss+xml"/><item><title>Systemd Timers: hora de aposentar o cron</title><link>https://devops.sarmento.org/posts/systemd-timers-hora-de-aposentar-o-cron/</link><pubDate>Mon, 23 Mar 2026 06:21:00 +0000</pubDate><guid>https://devops.sarmento.org/posts/systemd-timers-hora-de-aposentar-o-cron/</guid><description>&lt;p&gt;Se você administra servidores Debian ou Ubuntu há algum tempo, provavelmente tem uma relação de conforto com o cron. Uma linha no crontab, cinco campos de agendamento e o caminho do script — pronto, resolvido. O cron funciona assim desde os anos 1970, e essa simplicidade é justamente o que o manteve relevante por tanto tempo.&lt;/p&gt;
&lt;p&gt;O problema é que &amp;ldquo;funciona&amp;rdquo; e &amp;ldquo;funciona bem em 2026&amp;rdquo; são coisas diferentes. Quando um job falha silenciosamente às três da manhã, quando você precisa descobrir qual dos vinte crontabs espalhados pelo sistema contém aquela tarefa específica, ou quando o servidor reinicia e simplesmente perde a execução que deveria ter acontecido durante o downtime — nesses momentos o cron mostra que foi projetado para uma época em que as expectativas sobre observabilidade e resiliência eram outras.&lt;/p&gt;</description></item></channel></rss>