Résoudre le problème de la tâche cron ownCloud qui ne s'exécute pas : configurer un minuteur systemd fiable

Vous ouvrez la page d'administration d'ownCloud et constatez que les tâches en arrière-plan n'ont pas été exécutées récemment, ou que les tâches de nettoyage, d'activité, de stockage externe et autres tâches en file d'attente semblent retardées. Le réflexe courant est de modifier cron.phpou d'ajouter une entrée crontab. Or, la documentation actuelle d'ownCloud Server indique que ce n'est pas la meilleure solution : ownCloud recommande d'utiliser le mode d'arrière-plan Cron et la occ system:croncommande appropriée. Sur un système Linux, un minuteur systemd peut assurer la planification des tâches à la place de la crontab traditionnelle.

Ce guide se concentre sur une installation de type package ou bare-metal où ownCloud se trouve dans un répertoire tel que `/var/log/ /var/www/owncloudownCloud`. Si vous utilisez l'image Docker officielle d'ownCloud, arrêtez-vous avant de créer un minuteur hôte : ownCloud indique que l'image configure déjà cron en interne, via des variables telles que `cron_timer` OWNCLOUD_CROND_ENABLEDet `cron_timer`. Consultez la documentationOWNCLOUD_CROND_SCHEDULE actuelle sur les tâches en arrière-plan d'ownCloud .

Ce qui est vérifié, ce qui dépend de votre serveur et ce qui reste à vérifier

• Vérifié : ownCloud recommande Cron plutôt qu’AJAX pour une exécution fiable en arrière-plan, et documente occ system:cronla commande permettant d’exécuter des tâches en arrière-plan mises en file d’attente.
• Cela dépend de votre installation : le répertoire ownCloud, le binaire PHP, le compte serveur web, l’environnement PHP et le type d’installation (package, conteneur, appliance ou déploiement personnalisé).
• Impossible de déterminer, à partir d'un guide générique, la cause de l'échec de votre tâche. Il peut s'agir d'un problème de planification, mais aussi d'un problème d'autorisations, d'un chemin d'accès incorrect, d'une configuration différente de l'interface de ligne de commande PHP, d'un problème de connexion à la base de données, d'un verrouillage de fichier ou d'une défaillance d'une tâche en arrière-plan au niveau de l'application.

Action : ne créez pas de minuteur tant que la commande ownCloud exacte ne fonctionne pas manuellement avec le même compte que celui utilisé par le minuteur.

Étape 1 : Confirmer le mode Cron et tester ownCloud manuellement

Pour une installation Apache/Debian classique, l'utilisateur web est « web » www-data. Remplacez l'utilisateur et le chemin si votre environnement est différent.

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

La première commande active le mode de tâches en arrière-plan Cron d'ownCloud. La seconde exécute les tâches en arrière-plan mises en file d'attente. La documentation de la commande `occ` d'ownCloud précise qu'elle system:cronest conçue pour une exécution planifiée et que l'affichage de la progression ne doit pas être activé dans un planificateur non interactif.

Erreur fréquente : le « mode Cron » dans ownCloud ne signifie pas que vous devez utiliser le crondémon en particulier. Cela signifie qu’ownCloud attend un planificateur externe pour exécuter ses tâches en arrière-plan. Un minuteur systemd peut faire office de planificateur.

Action : si la commande manuelle échoue, corrigez d’abord cette erreur. Une minuterie ne fera que répéter la même erreur selon une planification.

Étape 2 : Trouver les chemins d’accès corrects à PHP et à ownCloud

Certaines installations rendent occle fichier exécutable directement ; d’autres sont plus prévisibles lorsqu’elles sont lancées avec l’invite de commandes PHP. Vérifiez les deux :

command -v php
readlink -f /var/www/owncloud/occ
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

La documentation d'ownCloud indique clairement que les tâches planifiées doivent trouver PHP et affiche donc les chemins complets dans les exemples cron. Cela est tout aussi important avec systemd, car les services bénéficient d'un environnement contrôlé et non de votre environnement shell interactif.

Action : remplacez /usr/bin/php, /var/www/owncloud, et www-datadans les exemples restants par les valeurs qui ont fonctionné sur votre hôte.

Étape 3 : Créer un service systemd à usage unique

Créer /etc/systemd/system/owncloud-cron.service:

[Unit]
Description=Run ownCloud background jobs
After=network.target

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

En général, il n'est pas nécessaire de prévoir une [Install]section pour le service, car le minuteur l'active. Le fait de conserver le service tel quel Type=oneshotsimplifie également la compréhension de son cycle de vie : il démarre, exécute la commande une fois, s'arrête et redevient inactif.

Idée reçue courante : un service à usage unique inactif n’est pas automatiquement interrompu. Après une exécution réussie, un service à usage unique RemainAfterExit=yesdevient normalement inactif.

Action : jugez le succès par le code de sortie et le journal, et non en vous attendant à ce que ce service reste « en fonctionnement ».

Étape 4 : Créer le minuteur systemd

Créer /etc/systemd/system/owncloud-cron.timer:

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

La documentation host-cron d'ownCloud recommande une planification de 15 minutes. Le minuteur ci-dessus respecte cette cadence. L'utilisation Persistent=trued'un OnCalendarminuteur est utile car systemd peut déclencher l'activation manquée du calendrier une fois la machine de nouveau disponible. Le comportement exact dépend toutefois de la version de systemd et de la durée d'indisponibilité de la machine.

Action : si vous avez besoin d’un intervalle différent, modifiez-le manuellement plutôt que de copier une valeur depuis un autre serveur. Une exécution plus fréquente peut augmenter la charge en arrière-plan ; une exécution moins fréquente peut retarder les tâches en file d’attente.

Étape 5 : Recharger systemd et activer le minuteur

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadPermet à systemd de relire les fichiers d'unité. enable --nowLes deux options activent le minuteur pour les démarrages futurs et le lancent immédiatement.

Action : si le minuteur n’est pas actif, vérifiez systemctl status owncloud-cron.timeravant de modifier à nouveau la configuration d’ownCloud.

Étape 6 : Vérifier les exécutions du minuteur suivant et précédent

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timersC'est le moyen le plus rapide de confirmer que systemd a programmé une prochaine activation et de voir quand le minuteur s'est déclenché pour la dernière fois. Cela permet de distinguer « le minuteur ne s'est jamais déclenché » de « le minuteur s'est déclenché, mais ownCloud a rencontré une erreur au sein du service ».

Action : si NEXT est absent ou si la minuterie n’est pas répertoriée, vérifiez à nouveau le nom du fichier de la minuterie, [Install]la section et si l’unité était activée.

Étape 7 : Consultez le journal d’entretien, et pas seulement le minuteur.

systemd enregistre les sorties de service dans le journal, sauf si vous les redirigez délibérément ailleurs. La documentation officielle de journalctl explique comment filtrer les entrées du journal par unité systemd.

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

Erreur fréquente : « Le minuteur est actif, donc la tâche cron d’ownCloud fonctionne. » Un minuteur actif indique seulement que le planificateur attend de se déclencher. Il faut toujours qu’un appel de service réussi soit effectué.

Action : recherchez les erreurs PHP, les messages d’autorisation refusée, les fichiers manquants, les erreurs de base de données ou un code de sortie différent de zéro. Corrigez la première erreur concrète plutôt que de redémarrer le minuteur à répétition.

Étape 8 : Déclenchez une exécution à la demande et vérifiez ownCloud

Vous n'avez pas besoin d'attendre 15 minutes pour un test final :

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

Après une exécution unique réussie, systemctl statusil est possible de signaler légitimement le service comme inactif tout en affichant un status=0/SUCCESSrésultat positif. L'important est que la commande se soit terminée avec succès.

Action : une fois le test de service manuel réussi, attendez au moins une activation de minuterie programmée et vérifiez qu’une nouvelle entrée de journal apparaît sans intervention manuelle.

Si le problème persiste : dépanner par couche

Note concernant cron.php et les guides plus anciens

Les anciennes instructions ownCloud font souvent appel cron.phpdirectement à la commande `git add`. La documentation ownCloud actuelle recommande d'utiliser une autre méthode occ system:cron, et les notes de version d'ownCloud expliquent la migration depuis l'ancienne cron.phpapproche directe. Consultez les notes de version d'ownCloud Server .

Action : si vous avez hérité d’une ancienne unité crontab ou systemd qui exécute cron.php, comparez-la avec la documentation de votre version ownCloud installée avant de la conserver.

Liste de vérification finale

• ownCloud est configuré pour les tâches en arrière-plan Cron.
• La commande exacte occ system:crons'exécute avec succès sous le compte serveur web prévu.
• owncloud-cron.timerest activé et active (waiting).
• systemctl list-timersaffiche à la fois une activation suivante et une activation précédente après un délai suffisant.
• journalctl -u owncloud-cron.serviceaffiche les exécutions planifiées réussies.
• Cette configuration ne duplique pas la tâche cron déjà fournie par l'image Docker officielle d'ownCloud ni par un autre planificateur.

Lorsque toutes ces vérifications sont réussies, vous avez vérifié bien plus que « la présence d’une minuterie » : vous avez démontré que systemd planifie la tâche, invoque ownCloud sous le bon compte et exécute avec succès le processus d’exécution en arrière-plan.