Scheduled Tasks und Cron-Integration
Scheduled Tasks und Cron-Integration
~13 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Unser app:list-overdue-tasks-Command aus Kapitel 39-40 ist nützlich, aber MUSS bisher manuell aufgerufen werden – Zeit, ihn AUTOMATISCH regelmäßig laufen zu lassen, um überfällige Aufgaben täglich per E-Mail zu melden.
Der klassische Weg: System-Cron
Der EINFACHSTE Ansatz nutzt den Cron-Daemon des Betriebssystems direkt:
# crontab -e
0 9 * * * cd /pfad/zum/projekt && php bin/console app:send-overdue-reminders --no-interaction >> var/log/cron.log 2>&10 9 * * * bedeutet "täglich um 9:00 Uhr". --no-interaction aus Kapitel 40 ist HIER ZWINGEND – ein Cron-Job kann NIEMALS auf eine interaktive Abfrage antworten. Die Ausgabe-Umleitung (>> ... 2>&1) protokolliert BEIDE Ausgabekanäle (normale Ausgabe UND Fehler) in eine Log-Datei, sonst geht die Ausgabe eines Cron-Jobs spurlos verloren.
Achtung: System-Cron hat einen praktischen Nachteil: die Konfiguration liegt AUSSERHALB des Projekt-Repositories, auf dem Server selbst – bei mehreren Umgebungen (Staging, Produktion) oder einem Server-Wechsel muss sie manuell übertragen und synchron gehalten werden, KEIN Teil der versionierten Codebasis.
Symfony Scheduler: die moderne Alternative
composer require symfony/schedulerSymfony Scheduler definiert Zeitpläne DIREKT im PHP-Code – VERSIONIERT, GEMEINSAM mit der übrigen Anwendungslogik, statt in externer Server-Konfiguration.
<?php
declare(strict_types=1);
namespace App\Scheduler;
use App\Message\UeberfaelligeErinnerungMessage;
use Symfony\Component\Scheduler\Attribute\AsSchedule;
use Symfony\Component\Scheduler\RecurringMessage;
use Symfony\Component\Scheduler\Schedule;
use Symfony\Component\Scheduler\ScheduleProviderInterface;
#[AsSchedule('aufgaben')]
class AufgabenSchedule implements ScheduleProviderInterface
{
public function getSchedule(): Schedule
{
return (new Schedule())->add(
RecurringMessage::cron('0 9 * * *', new UeberfaelligeErinnerungMessage())
);
}
}GENAU dieselbe Cron-Syntax ('0 9 * * *') wie beim System-Cron oben – Symfony übernimmt intern die Zeitplan-Berechnung, statt sich auf den Betriebssystem-Daemon zu verlassen.
Den Scheduler-Worker starten
php bin/console messenger:consume scheduler_aufgabenDieser Prozess läuft DAUERHAFT im Hintergrund (z. B. via Supervisor oder systemd auf dem Produktionsserver) und löst die konfigurierten Nachrichten zum RICHTIGEN Zeitpunkt aus – das UeberfaelligeErinnerungMessage-Objekt landet dann bei einem zugehörigen Message Handler, der z. B. GENAU unseren app:list-overdue-tasks-Command-Logik (oder eine E-Mail-Variante davon) aufruft.
Faustregel: System-Cron vs. Symfony Scheduler
| Ansatz | Eigenschaften |
|---|---|
| System-Cron | Einfach, KEINE zusätzliche Abhängigkeit, aber Konfiguration liegt AUSSERHALB des Codes – gut für sehr einfache, seltene Projekte. |
| Symfony Scheduler | Zeitpläne VERSIONIERT im Code, dynamisch anpassbar (z. B. Zeitplan aus der Datenbank laden), aber braucht einen DAUERHAFT laufenden Worker-Prozess – die empfohlene Wahl für Anwendungen mit mehreren geplanten Aufgaben. |
Tipp: Für DIESES Kapitel reicht das Prinzip-Verständnis – die vollständige Messenger-Infrastruktur (Message Handler, Transport-Konfiguration) würde den Rahmen dieser Schulung sprengen und ist bewusst nur als Ausblick erwähnt, GENAU wie der asynchrone Mailer-Versand aus Kapitel 38.