Résoudre les problèmes de tâches cron Nextcloud qui ne s'exécutent pas automatiquement avec systemd

Pour automatiser l'exécution des tâches en arrière-plan de Nextcloud avec systemd, configurez un service ponctuel s'exécutant cron.phpavec les privilèges de l'utilisateur du serveur web, puis activez une minuterie qui redémarre ce service toutes les cinq minutes. Les points essentiels à vérifier sont : l'activation de la minuterie et la définition d'une prochaine exécution ; la configuration correcte des chemins d'accès à Nextcloud et PHP pour le service ; et la confirmation de la bonne fin d'exécution dans le journal du service. Il est possible qu'un service ponctuel affiche l'état « inactif (mort) » entre deux exécutions ; ce comportement est normal une fois son exécution terminée.

Cette configuration est prévue pour une installation classique de Nextcloud sur Ubuntu utilisant systemd, avec les fichiers Nextcloud disponibles sur l'hôte. Si Nextcloud s'exécute dans un conteneur Docker, Snap ou une appliance comme Nextcloud All-in-One, utilisez la méthode de planification documentée de cette distribution au lieu de pointer une unité hôte vers un chemin réservé aux conteneurs. Les exemples ci-dessous utilisent `<chemin_installation>` /var/www/nextcloudet ` www-data<utilisateur_HTTP>` ; remplacez-les par le chemin d'installation réel et l'utilisateur HTTP sur votre serveur.

Ce que le minuteur devrait accomplir

Nextcloud cron.phpexécute des tâches en arrière-plan mises en file d'attente, telles que la maintenance et les tâches applicatives. Le minuteur systemd fait office d'horloge ; le service correspond à la commande qui s'exécute lorsque le minuteur arrive à échéance. Les deux sont nécessaires. Créer les fichiers sans activer le minuteur rend la planification inactive, tandis qu'activer un minuteur pointant vers un chemin PHP ou Nextcloud incorrect peut entraîner des échecs d'exécution répétés.

Nextcloud recommande l'utilisation de cron système pour les tâches d'arrière-plan en production. Son manuel d'administration actuel mentionne également les minuteurs systemd comme alternative. La planification d'exemple démarre cinq minutes après le démarrage du système, puis se répète cinq minutes après chaque activation de service. Elle évite ainsi à l'utilisateur de devoir consulter l'interface web.

1. Vérifiez le chemin d'installation, l'utilisateur et l'interface de ligne de commande PHP.

Avant de modifier les unités, localisez le répertoire Nextcloud et vérifiez la commande PHP attendue par l'installation du serveur web. Sur une installation Ubuntu classique, le chemin peut être `/etc/nextcloud` /var/www/nextcloud, l'utilisateur web est souvent `user` www-dataet la ligne de commande PHP est `php-cli` /usr/bin/php. Vérifiez plutôt que de supposer :

ls -l /var/www/nextcloud/cron.php
command -v php
php -v

Si votre répertoire Nextcloud se trouve ailleurs, indiquez son emplacement dans les deux commandes unitaires ci-dessous. Si le serveur web utilise une version PHP distincte, utilisez l'exécutable CLI correspondant ExecStart. ExecConditionUn service systemd n'hérite pas du PATH ni de l'environnement de l'interpréteur de commandes interactif ; par conséquent, les chemins explicites sont plus fiables.

Effectuez le test d'état avec le même utilisateur que celui utilisé par systemd :

sudo -u www-data /usr/bin/php -f /var/www/nextcloud/occ status -e

La commande Nextcloud occdoit être exécutée en tant qu'utilisateur HTTP afin de préserver la propriété et les permissions des fichiers. Si ce test signale une erreur PHP, un mode maintenance ou un fichier manquant, veuillez résoudre ce problème en premier lieu ; le chronomètre ne peut pas compenser un échec de la commande Nextcloud.

2. Créer le service ponctuel

Créer /etc/systemd/system/nextcloudcron.service:

sudo nano /etc/systemd/system/nextcloudcron.service

Saisissez cette unité, en adaptant le chemin d'accès et l'utilisateur si votre installation diffère :

[Unit]
Description=Nextcloud cron.php job

[Service]
User=www-data
ExecCondition=/usr/bin/php -f /var/www/nextcloud/occ status -e
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php
KillMode=process

ExecConditionCe service vérifie le bon fonctionnement de Nextcloud avant de lancer la tâche en arrière-plan. En cas d'échec, systemd ignore l'exécution ; consultez le journal pour en connaître la raison. KillMode=processIl permet aux programmes externes lancés par une tâche en arrière-plan de continuer à fonctionner après l'arrêt du processus cron principal. L'exemple Nextcloud actuel ne nécessite pas de [Install]section dans ce fichier de service.

Son utilisation /usr/bin/phpest appropriée uniquement si c'est l'interpréteur de commandes correct sur votre serveur. Par exemple, un dépôt PHP personnalisé peut installer un binaire versionné. Utilisez la même version de PHP compatible que celle requise par Nextcloud et utilisée dans la configuration de son serveur web.

3. Créez le minuteur

Créer /etc/systemd/system/nextcloudcron.timer:

sudo nano /etc/systemd/system/nextcloudcron.timer

Ajouter:

[Unit]
Description=Run Nextcloud cron.php every 5 minutes

[Timer]
OnBootSec=5 min
OnUnitActiveSec=5 min
Unit=nextcloudcron.service

[Install]
WantedBy=timers.target

OnBootSecLa première exécution est planifiée cinq minutes après le démarrage de systemd au démarrage du système. OnUnitActiveSecUne autre exécution est planifiée cinq minutes après la dernière activation du service. Le minuteur est indépendant du service : activez et démarrez l’ .timerunité pour que la planification s’exécute automatiquement.

4. Rechargez systemd et activez le minuteur.

Demandez à systemd de lire les nouveaux fichiers d'unité, puis activez et démarrez le minuteur en une seule commande :

sudo systemctl daemon-reload
sudo systemctl enable --now nextcloudcron.timer

Vérifiez le minuteur :

systemctl status nextcloudcron.timer
systemctl list-timers --all | grep nextcloudcron

Le minuteur doit être chargé et actif, et list-timersafficher une heure future sous « SUIVANT ». S'il est désactivé, non chargé ou n'affiche aucune activation suivante, vérifiez que le nom du fichier se termine par `.txt` .timer, que la [Install]section `.txt` contient ` .txt` WantedBy=timers.targetet que vous avez exécuté la commande daemon-reloadaprès avoir enregistré les fichiers.

5. Effectuez un test et examinez son résultat.

Vous pouvez lancer le service une seule fois sans attendre le prochain incrément du minuteur :

sudo systemctl start nextcloudcron.service
sudo systemctl status nextcloudcron.service
sudo journalctl -u nextcloudcron.service -n 50 --no-pager

Vérifiez le résultat du service et les éventuelles erreurs PHP ou Nextcloud. Une fois la commande terminée, le système nextcloudcron.servicepeut revenir à l'état inactive (dead)initial, car il s'agit d'une tâche ponctuelle. Cela ne signifie pas pour autant qu'elle a échoué. Le minuteur devrait rester actif et planifier la prochaine exécution ; le journal devrait indiquer si l'exécution précédente s'est terminée correctement.

Dans les paramètres d'administration de Nextcloud, ouvrez la section « État des tâches en arrière-plan » et vérifiez que la durée de la dernière exécution s'incrémente après le déclenchement du minuteur. L'avertissement devrait disparaître lorsque Nextcloud détecte une activité récente en arrière-plan. Attendez au moins un intervalle après l'activation du minuteur avant de conclure que la tâche planifiée n'a pas été exécutée.

Diagnostiquer les modes de défaillance courants

Pour plus de détails, consultez les journaux de service récents et le fichier journal de Nextcloud :

sudo journalctl -u nextcloudcron.service --since "30 minutes ago" --no-pager
sudo -u www-data /usr/bin/php -f /var/www/nextcloud/occ background-job:list

La liste des tâches affiche les travaux enregistrés, mais elle ne prouve pas à elle seule que le minuteur est en cours d'exécution. Utilisez conjointement les dates et heures de dernière et prochaine activation du minuteur, le journal du service et l'indicateur de dernière exécution de Nextcloud.

Quand utiliser un autre planificateur

Les minuteurs systemd sont parfaitement adaptés lorsque le serveur utilise systemd et que vous souhaitez une planification locale gérée par un service. Si vous utilisez déjà un démon cron standard et que vous pouvez vérifier son crontab, une entrée cron système effectuant le même appel est également prise cron.phpen www-datacharge. Évitez de planifier les deux méthodes pour la même instance Nextcloud ; les appels simultanés peuvent gaspiller des ressources et compliquer le dépannage.

La planification AJAX dépend des utilisateurs qui consultent Nextcloud et est moins fiable pour un serveur très sollicité ou partagé par plusieurs utilisateurs. Les appels Webcron cron.phpvia HTTP peuvent convenir à une instance très réduite où l'accès au système est impossible, mais Nextcloud précise que l'exécution web limite la quantité de travail pouvant être exécutée par appel. Si Nextcloud est conteneurisé ou géré par un dispositif dédié, utilisez son planificateur ou sa configuration de conteneur compatibles ; un service hôte utilisant /var/www/nextcloudcette configuration ne fonctionnera pas si le chemin d'accès n'est pas présent sur l'hôte.

Une configuration saine comprend un minuteur activé avec une exécution régulière à la prochaine heure, des exécutions de service se terminant sans erreur PHP et une date de dernière exécution de Nextcloud qui s'incrémente. Si ces trois conditions sont remplies, mais qu'une tâche applicative particulière semble toujours retardée, il est possible que le planificateur soit en cours d'exécution pendant que cette tâche attend son propre calendrier, une fenêtre de maintenance ou des conditions de file d'attente. Diagnostiquez cette tâche séparément avant de modifier l'intervalle du minuteur.

Références officielles

• Manuel d'administration de Nextcloud 35 : Tâches en arrière-plan et minuteurs systemd
• Manuel d'administration de Nextcloud : Utilisation de la commande occ
• Manuel d'administration de Nextcloud 35 : Commandes des tâches en arrière-plan
• Manuel d'utilisation de systemd.timer sous Ubuntu 24.04