Queueworkers en geplande taken

Een native Linux-installatie van Agovena heeft twee achtergrondprocessen nodig:

1. Een blijvende queueworker voor taken zoals e-mail, webhooks, abonnementen en provisioning.
2. Een cronjob die iedere minuut de Laravel-scheduler uitvoert.

De winkel kan zonder deze processen laden, maar wachtrijtaken en geplande taken stoppen dan.

1. Installeer cron

Gebruik de tab voor jouw besturingssysteem wanneer cron nog niet is geïnstalleerd:

sudo apt update
sudo apt install -y cron
sudo systemctl enable --now cron

sudo apt-get update
sudo apt-get install -y cron
sudo systemctl enable --now cron

2. Voeg de Agovena-cronjob toe

Open de crontab van dezelfde runtimegebruiker die de applicatie kan lezen en naar storage/ en bootstrap/cache/ kan schrijven. De meegeleverde deployment gebruikt www-data:

sudo -u www-data crontab -e

Voeg deze ene regel toe:

* * * * * cd /var/www/agovena && /usr/bin/php artisan schedule:run >> /dev/null 2>&1

Behoud andere cronjobs in het bestand. Staat PHP ergens anders geïnstalleerd? Gebruik dan het pad uit command -v php. Is jouw PHP-FPM- of queuegebruiker niet www-data, vervang die gebruikersnaam dan in de opdracht.

Controleer de opgeslagen regel:

sudo -u www-data crontab -l

3. Installeer de queueworker

Kopieer de systemd-unit van Agovena en schakel deze in:

cd /var/www/agovena
sudo cp deploy/systemd/agovena-queue.service /etc/systemd/system/agovena-queue.service
sudo systemctl daemon-reload
sudo systemctl enable --now agovena-queue.service

De unit voert deze worker uit:

/usr/bin/php /var/www/agovena/artisan queue:work --sleep=1 --tries=3 --timeout=60 --backoff=5 --max-time=3600

Wijkt jouw PHP-pad, applicatiepad of runtimegebruiker af? Bewerk dan /etc/systemd/system/agovena-queue.service voordat je hem start. Herlaad daarna systemd opnieuw.

Controleer de worker:

sudo systemctl status agovena-queue.service
sudo journalctl -u agovena-queue.service -n 50 --no-pager

Gebruik voor één worker óf deze systemd-unit óf de meegeleverde Supervisorconfiguratie. Draai niet beide voor dezelfde queue.

4. Controleer geplande taken

Voer deze opdrachten uit vanuit de applicatiemap:

cd /var/www/agovena
php artisan schedule:list
php artisan schedule:run
php artisan agovena:doctor

schedule:list toont de geregistreerde planning. schedule:run voert taken uit die aan de beurt zijn. Het verandert dus applicatiestatus en is niet alleen een diagnose.

De scheduler behandelt terugkerend applicatiewerk zoals webhookbezorging, reconciliatie van uitgestelde betalingen, abonnementsverlengingen, provisioningsynchronisatie en back-upplanning. Welke taken draaien hangt ook af van actieve modules en winkelinstellingen.

Controleer na de eerste verstreken minuut Admin → Cronstatistieken, Mislukte taken en Updates.

5. Herstart na updates

Workers houden geladen applicatiecode in het geheugen. Herstart ze na nieuwe bestanden of gewijzigde omgeving:

cd /var/www/agovena
php artisan queue:restart
sudo systemctl restart agovena-queue.service

De procesbeheerder moet de worker opnieuw starten wanneer deze afsluit. Laat de scheduler-cronjob tijdens updates staan, tenzij de updatehandleiding vraagt om hem tijdelijk te pauzeren.

6. Docker Compose

Docker Compose draait worker met queue:work en scheduler met schedule:work. Voeg voor de Compose-scheduler geen native host-cronjob toe. Volg de Docker Compose-handleiding en houd beide services actief:

docker compose -f docker-compose.prod.yml up -d worker scheduler
docker compose -f docker-compose.prod.yml ps

7. Problemen met achtergrondwerk oplossen

Verwerkt de queue geen taken?

1. Controleer systemctl status agovena-queue.service.
2. Lees de laatste workerlogs met journalctl.
3. Controleer Admin → Mislukte taken.
4. Controleer of de queueverbinding in .env overeenkomt met de geconfigureerde database- of Redis-service.
5. Voer php artisan agovena:doctor uit en lees naast de exitcode ook de waarschuwingen.

Draait gepland werk niet? Controleer de crontab, het PHP-pad, de runtimegebruiker en de schedulerheartbeat. Controleer bij betalingen of provisioning eerst de externe provider voordat je een mislukte taak opnieuw uitvoert, om een dubbele externe handeling te voorkomen.