Owncloud - cron.php tourne en permanence, occupant tout la mémoire

Bonjour,
Depuis la dernière mise à jour d’owncloud (via le paquet yunohost), mon cron.php se bloque et utilise toute la mémoire de mon serveur. Le seule solution à l’heure actuelle est de tuer le process à la main, ce qui est loin d’être idéal.
Je ne vois rien d’évident dans les logs owncloud ou php, et surtout rien de lié à cron.php. Voici mon log php:

[14-Jul-2016 17:00:43] WARNING: [pool owncloud] child 714, script '/var/www/owncloud//remote.php' (request: "REPORT /owncloud/remote.php") executing too slow (6.595266 sec), logging
[14-Jul-2016 17:00:43] NOTICE: child 714 stopped for tracing
[14-Jul-2016 17:00:43] NOTICE: about to trace 714
[14-Jul-2016 17:00:43] ERROR: failed to ptrace(PEEKDATA) pid 714: Input/output error (5)
[14-Jul-2016 17:00:43] NOTICE: finished trace of 714
[14-Jul-2016 17:00:54] WARNING: [pool owncloud] child 2334, script '/var/www/owncloud//remote.php' (request: "OPTIONS /owncloud/remote.php") executing too slow (6.382985 sec), logging
[14-Jul-2016 17:00:54] NOTICE: child 2334 stopped for tracing
[14-Jul-2016 17:00:54] NOTICE: about to trace 2334
[14-Jul-2016 17:00:54] ERROR: failed to ptrace(PEEKDATA) pid 2334: Input/output error (5)
[14-Jul-2016 17:00:54] NOTICE: finished trace of 2334
[14-Jul-2016 19:31:55] WARNING: [pool owncloud] server reached pm.max_children setting (6), consider raising it
[14-Jul-2016 19:31:58] WARNING: [pool owncloud] child 6202, script '/var/www/owncloud//remote.php' (request: "OPTIONS /owncloud/remote.php") executing too slow (5.142224 sec), logging
[14-Jul-2016 19:31:58] WARNING: [pool owncloud] child 2334, script '/var/www/owncloud//remote.php' (request: "GET /owncloud/remote.php") executing too slow (5.153436 sec), logging
[14-Jul-2016 19:31:58] WARNING: [pool owncloud] child 714, script '/var/www/owncloud//remote.php' (request: "OPTIONS /owncloud/remote.php") executing too slow (5.199807 sec), logging
[14-Jul-2016 19:31:59] NOTICE: child 6202 stopped for tracing
[14-Jul-2016 19:31:59] NOTICE: about to trace 6202
[14-Jul-2016 19:31:59] NOTICE: finished trace of 6202
[14-Jul-2016 19:31:59] NOTICE: child 714 stopped for tracing
[14-Jul-2016 19:31:59] NOTICE: about to trace 714
[14-Jul-2016 19:31:59] NOTICE: finished trace of 714
[14-Jul-2016 19:31:59] NOTICE: child 2334 stopped for tracing
[14-Jul-2016 19:31:59] NOTICE: about to trace 2334
[14-Jul-2016 19:31:59] NOTICE: finished trace of 2334
[14-Jul-2016 19:32:22] WARNING: [pool owncloud] child 715, script '/var/www/owncloud//remote.php' (request: "GET /owncloud/remote.php") executing too slow (5.965722 sec), logging
[14-Jul-2016 19:32:22] NOTICE: child 715 stopped for tracing
[14-Jul-2016 19:32:22] NOTICE: about to trace 715
[14-Jul-2016 19:32:22] NOTICE: finished trace of 715
[14-Jul-2016 19:33:23] WARNING: [pool owncloud] child 2333, script '/var/www/owncloud//remote.php' (request: "OPTIONS /owncloud/remote.php") executing too slow (5.061888 sec), logging
[14-Jul-2016 19:33:23] NOTICE: child 2333 stopped for tracing
[14-Jul-2016 19:33:23] NOTICE: about to trace 2333

et dans mon log owncloud, uniquement des événements liés à ma synchro caldav.

Le problème reste le même si je lance le process manuellement, et il n’y a aucune info sur ce qui se passe.

Quelqu’un a une idée de ce que je pourrais faire pour comprendre où cron.php bloque ? Un moyen de tracer la fuite mémoire ?

Merci

EDIT: Pour info j’ai remarqué que le disque dur grattait pas mal à ces moments là. J’ai des répertoires samba montés avec owncloud, qui sont configurés pour n’être rafraîchit que lorsqu’on navigue dedans. Reste à savoir si c’est bien ça le problème, et ensuite comment le résoudre.

Salut, est-ce qu’une fois que tu as tué la tâche cron en cours, tu pourrais lancer la commande suivante (qui correspond à la tache cron) pour voir ce qui pourrait bloquer :

sudo sudo -u owncloud /usr/bin/php -f /var/www/owncloud/cron.php

Si ce n’est pas assez bavard, tu peux également changer le niveau de log en modifiant le fichier /var/www/owncloud/config/config.php et en ajoutant dans le tableau (0 pour DEBUG, voir la doc) :

    'loglevel' => 0,

Salut Jérôme,

J’avais effectué ça mais cela n’avait pas donné beaucoup plus de détails.

Par contre j’ai réussi à ne plus avoir le problème (en tout cas dans les 5 dernières heures) en supprimant un dossier monté en samba qui pointait vers mon NAS et qui était aussi synchronisé en local sur mes PC via l’application owncloud. je suis repassé à un montage plus classique, toujours samba mais directement via debian et fstab au lieu de la configuration avec owncloud.

Et je viens de comprendre pourquoi j’avais plein de soucis. Lors de l’upgrade d’Owncloud, le fichier config.php a été mis à jour. Or je l’avais modifié pour que mon dossier data soit sur mon point de montage samba.

On peut considérer ça comme un bug dans le paquet owncloud de yunohost ou on considère que l’utilisateur modifie un fichier de configuration à ses risques et périls ? J’avais fait l’installation avec le dossier data par défaut, et changé son emplacement par la suite.

On arrive quand même dans un usage assez avancé, où il commence à être vraiment difficile de tenter d’anticiper tous les éventuels problèmes liés à une opération manuelle de l’utilisateur… Vu comment ownCloud est fait niveau gestion de la configuration, il est plus difficile (ou en tout cas plus délicat) de faire comme pour Roundcube, c’est-à-dire charger un fichier de configuration local qui ne sera pas écrasé à la mise à jour (expliqué ici). Enfin, on peut tenter de le faire si la demande est là et que ça devient bloquant… (dans ton cas, si j’ai bien compris, ça le sera à la prochaine mise à jour)

La prochaine fois je ferai gaffe :wink:
Je comprends que ça puisse être compliqué. Autant dans le cas de ma modif il y a très peu de risque à garder les modifs d’une version à une autre, autant d’autres configurations plus complexes pourraient causer des problèmes. En plus il suffit qu’Owncloud ou Nextcloud change la structure du config.php et ça va devenir complexe.
Peut-être uniquement rajouter une sauvegarde du fichier à la mise à jour et prévenir l’utilisateur qu’il a été écrasé.

J’ai ouvert un ticket sur le bugtracker (voir #454), j’essayerai de le faire à l’occasion !

Mais je pense quand même que gérer le changement par l’utilisateur du répertoire où se trouve les données est quand même pas rien… Et c’est plus que nécessaire de savoir où il se trouve lors de la sauvegarde / restauration. Au lieu de le changer, je proposerai plutôt de modifier ton point de montage pour le faire pointer dans /home/yunohost.app/owncloud/data plutôt que /mnt/... si tu en as la possibilité, ou de faire un lien symbolique (à voir laquelle de ces 2 propositions parmi d’autres est la mieux gérée par la sauvegarde).

Ok merci je vais essayer avec un lien symbolique d’abord : j’utilisais ce point de montage pour plusieurs choses (owncloud, sonerezh, backup, jirafeau) donc ça serait le plus simple. Reste à vérifier que ça ne pause aucun problème, sinon je passerai effectivement au montage directement dans /home/yunohost.app/owncloud/data avec une possible duplication sur le NAS, mais tant pis c’est un QNAP 8 baies derrière, j’ai de la place :slight_smile:
Merci de ton aide.