<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Cron on stefansblog</title>
  <link rel="alternate" href="https://stefansblog.org/tags/cron/" />
  <link rel="self" href="https://stefansblog.org/tags/cron/index.xml" />
  <subtitle>Recent content in Cron on stefansblog</subtitle>
  <id>https://stefansblog.org/tags/cron/</id>
  <generator uri="http://gohugo.io" version="0.137.1">Hugo</generator>
  <language>en</language>
  <updated>2026-08-18T23:37:00+02:00</updated>
  <author>
    <name>Stefan Sebekow</name>
    
  </author>
  
      <entry>
        <title>Systemd-Timer statt Cronjobs - Jobs im Homelab planen &amp; automatisieren</title>
        <link rel="alternate" href="https://stefansblog.org/posts/systemd_timer-statt-cronjob/" />
        <id>https://stefansblog.org/posts/systemd_timer-statt-cronjob/</id>
        <published>2026-08-18T23:37:00+02:00</published>
        <updated>2026-08-18T23:37:00+02:00</updated>
        <summary type="html">&lt;p&gt;Der klassische Cron-Daemon ist unter Linux nach wie vor das Werkzeug der Wahl, wenn es darum geht, einen schnellen Befehl zu einer bestimmten Uhrzeit in die Crontab zu werfen. Wenn ein modernes Linux-System aber ohnehin vollständig von &lt;code&gt;systemd&lt;/code&gt; verwaltet wird, sind &lt;code&gt;systemd.timer&lt;/code&gt;-Units für wiederkehrende Aufgaben oft die elegantere und robustere Lösung.&lt;/p&gt;
&lt;p&gt;Ein großer Vorteil von &lt;code&gt;systemd&lt;/code&gt;-Timern liegt im modularen Aufbau: Der Timer selbst übernimmt niemals die eigentliche Aufgabe. Seine einzige Pflicht ist es, eine separate &lt;code&gt;.service&lt;/code&gt;-Unit zu triggern, die anschließend den Job ausführt. Zeitplanung und Programmlogik bleiben dadurch getrennt. Der Scheduler ist direkt in die Serviceverwaltung integriert, Jobs haben einen eigenen Unit-Status und die Ausführung landet automatisch im Journal.&lt;/p&gt;</summary>
      </entry>

</feed>


