Exécutez des tâches en arrière-plan ownCloud de manière fiable grâce à un minuteur Systemd.

Si la page d'administration d'ownCloud indique que les tâches en arrière-plan ne sont pas en cours d'exécution, le nettoyage en file d'attente et les autres tâches planifiées peuvent être retardés jusqu'à ce qu'un utilisateur visite le site. Sur un serveur Linux géré par systemd, configurez le mode de tâches en arrière-plan d'ownCloud pour Cron et utilisez un minuteur pour l'exécuter occ system:cronavec le compte du serveur web. La documentation actuelle d'ownCloud Server recommande l'utilisation de cron système pour les tâches régulières en arrière-plan et mentionne spécifiquement les minuteurs systemd comme une autre méthode pour planifier des commandes.

Ce guide concerne ownCloud Server Classic installé directement sur un hôte Linux. Il ne s'applique pas à ownCloud Infinite Scale, dont l'architecture est différente, ni à l'image Docker officielle d'ownCloud, qui exécute déjà cron en interne. Dans ce cas, suivez les paramètres documentés de l'image au lieu de créer un second minuteur hôte. Consultez la documentation actuelle sur les tâches en arrière-plan d'ownCloud Server .

Vérifiez la commande avant de modifier la planification

Un service systemd définit la commande à exécuter ; un minuteur lance ce service périodiquement. Commencez par vérifier le chemin d'installation d'ownCloud et le compte du serveur HTTP. Les exemples ci-dessous utilisent `username` /var/www/owncloudet www-data`username`, courants sur Debian et Ubuntu. D'autres distributions Linux peuvent utiliser `username` wwwrun, apache`username` ou un autre compte.

Exécutez manuellement la commande ownCloud avec ce compte pour distinguer une commande défectueuse d'une planification défectueuse :

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

Modifiez le chemin d'accès et l'exécutable PHP pour occqu'ils correspondent à votre serveur. ownCloud recommande l'utilisation de `php system:cronip` pour les tâches en arrière-plan ; les anciens guides concernant la planification cron.phppeuvent faire référence à des comportements obsolètes. Une commande en cours peut se terminer sans afficher de message de réussite ; vérifiez donc son code de sortie echo $?immédiatement après : 0`php ip` signifie que la commande s'est terminée avec succès. Si `php ip` renvoie une erreur, corrigez d'abord le chemin d'accès, l'installation de l'interface de ligne de commande PHP, les permissions, la connexion à la base de données ou une erreur ownCloud. Si vous ignorez cette vérification, le minuteur exécutera la même commande en échec de manière répétée.

Configurer ownCloud en mode Cron

Dans les paramètres d'administration d'ownCloud, ouvrez la section « Tâches en arrière-plan » ou « Cron » et sélectionnez « Cron » . Vous pouvez également configurer le planificateur depuis le répertoire d'installation :

cd /var/www/owncloud
sudo -E -u www-data php occ background:cron

Ceci active le mode Cron ; la commande planifiée reste inchangée occ system:cron. Le manuel d'ownCloud indique que cette commande est équivalente à la sélection de Cron dans la page d'administration. Cron est préférable pour un serveur qui doit traiter les tâches de manière fiable, car AJAX dépend des visites de pages et peut laisser des tâches en attente pendant les périodes d'inactivité. Pour une petite instance personnelle, AJAX peut être plus simple, mais il est moins prévisible.

Créer le service systemd et le minuteur

Créez un compte /etc/systemd/system/owncloudcron.serviceavec votre compte HTTP et votre chemin d'accès ownCloud :

[Unit]
Description=ownCloud background jobs

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

Type=oneshotCette commande indique à systemd qu'elle s'exécute jusqu'à son terme puis se termine. Spécifier le chemin complet de PHP évite de dépendre des ressources limitées PATHdisponibles pour les services système. Le répertoire de travail aide ownCloud à résoudre les chemins relatifs. Assurez-vous que le compte de service corresponde à celui du propriétaire des fichiers et des données ownCloud. N'exécutez pas la tâche en tant que superutilisateur (root).

Ensuite, créez /etc/systemd/system/owncloudcron.timer:

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

[Timer]
OnBootSec=5min
OnUnitActiveSec=15min
Unit=owncloudcron.service

[Install]
WantedBy=timers.target

Le manuel d'ownCloud recommande un intervalle de 15 minutes pour son exemple standard de tâche cron et mentionne les minuteurs systemd comme alternative. Ce minuteur démarre cinq minutes après le démarrage du système, puis planifie d'autres exécutions 15 minutes après l'activation du service. Si votre charge de travail nécessite un autre intervalle, modifiez-le OnUnitActiveSecjudicieusement et tenez compte du temps nécessaire à chaque exécution. Évitez de configurer une autre entrée crontab pour la même commande ; des planificateurs dupliqués peuvent lancer des exécutions redondantes et compliquer le dépannage.

Demandez à systemd de recharger ses définitions d'unités, puis activez et démarrez le minuteur :

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

daemon-reloadCette opération est requise après la création ou la modification de fichiers d'unité. L'activation du minuteur permet un démarrage automatique lors des prochains redémarrages ; --nowil démarre également dans la session en cours. Activez l'unité du minuteur, et non le service.

Déterminez pourquoi une exécution a été ignorée ou a échoué.

Vérifiez si la minuterie est activée et quand elle s'exécutera de nouveau :

systemctl is-enabled owncloudcron.timer
systemctl list-timers --all owncloudcron.timer
systemctl status owncloudcron.timer

Un minuteur activé devrait apparaître dans la liste des minuteurs avec une prochaine activation. Si ce n'est pas le cas, vérifiez le nom du fichier de l'unité, rechargez systemd et réactivez le minuteur. Si le minuteur indique une exécution mais que le traitement d'ownCloud est toujours retardé, examinez le service et ses journaux :

systemctl status owncloudcron.service
sudo journalctl -u owncloudcron.service --since today

Recherchez un chemin d'accès incorrect, un répertoire de données inaccessible, une extension PHP manquante ou une erreur de base de données. Testez manuellement la commande exacte du fichier de service afin www-datade reproduire l'environnement au plus près. Vérifiez également que vous avez bien utilisé la commande ownCloud occ system:cron, et non pas copié un exemple Nextcloud qui l'invoque cron.php.

Vérifiez que ownCloud traite bien les tâches.

Après un ou deux intervalles de minuterie, vérifiez que le service s'est bien terminé et qu'une nouvelle activation est programmée. Consultez ensuite l'état de la tâche en arrière-plan sur la page d'administration d'ownCloud. La date et l'heure de la dernière exécution affichées devraient avoir progressé et l'avertissement Cron obsolète devrait disparaître. Si systemd signale une réussite mais que l'avertissement persiste, examinez le journal d'application d'ownCloud et vérifiez si l'interface web est connectée à la même instance et à la même base de données que l'installation en ligne de commande.

Pour les conteneurs ownCloud officiels, n'installez pas ces unités hôtes sauf si vous avez intentionnellement désactivé le planificateur interne du conteneur et que la documentation ownCloud actuelle prend en charge votre configuration. La configuration présentée ici est une solution au niveau de l'hôte pour ownCloud classique sur systemd ; les noms de service, les chemins d'accès, les versions de PHP et le comportement du conteneur dépendent du déploiement.