antbel
Merci, mais cautère sur une jambe de bois.
avec la version précédente de php tu avais ce problème ???
VINDICATORs
Non, c'est pour cela que je parle de la 8. Je n'y faisais pas attentions lors du passage à Fedora 35, car j'avais abaissé la charge maximale de la mémoire vive qui se trouvait être le plus urgent à faire (des oomkiller régulier c'est pénible...). Cela avait calmé les choses, mais pas la charge processeur...
Mais un test sur une Fedora 36 en virtuel a confirmé le problème.
Généralement cela prend 1 cœurs à 100% tous les jours. Mais par moment il utilise 4 à 5 processus avec 1 coeurs à chaque fois par semaine...
Mais là maintenant cela ne dure plus avec le "kill" forcé si nécessaire.
J'en ai aussi profité pour améliorer les réglages de performance tant de Apache, que de php/php-fpm... Je vais pouvoir revoir mes réglages de la mémoire, car j'ai parfois un peu trop limité du coup...
Cela vas me permettre de lancer la migration vers Fedora 36 du coup, le doute sur la sécurité et l'étonnement de ce problème avait repoussé l'échéance. Après j'attends toujours au moins un mois avant de le faire...
antbel
wait a little bit & :pint:
Nicosss
Concrètement tu t'en es aperçu comment et avec quelle méthode ?
Avec la solution d'utiliser
systemd tu as le même comportement
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/background_jobs_configuration.html ?
VINDICATORs
Top atop htop. Et un :
ps -eaf | grep php
Retourne la commande php du cron.php de nextcloud, normalement cela dure au mieux 2 minutes toutes les 5 minutes. Mais là il ne s'arrêté plus par moment, avec parfois plusieurs processus dans ce cas.
Je ne l'avais pas vu avant car depuis la limitation de la RAM avec php/php fpm je n'avais plus de gros blocages.
Et comme j'ai par la suite travaillé surtout sur la sécurité, du coup je faisais pas mal de redémarrage machines/services.
Du coup je n'ai pas vu que les ressources processeur étaient saturés jusqu'à ce samedi. Mais je pensé que c'était mes réglages de sécurités qui n'étaient pas correct, voir des attaques non bloqués... Ce qui ne fut pas le cas (même si du coup cela m'a fait améliorer pas mal de points... et surtout améliorer le bloquage des quelques tentatives...) a ce niveau.
A voir par la suite pour systemd. Cela tourne très bien avec cron pour le moment.
Édit : après c'est surtout le boucan des ventilateurs du serveur qui m'ont alerté ce samedi..
Nicosss
Je ne rencontre pas ce souci avec l'utilisation de systemd.
Ça serait à essayer pour confirmer.
VINDICATORs
Comme je l'ai dit, c'est entre php 8 et cron qu'il y a un souci.
Je verrais pour passer à systemd qui est plus indépendant. Par contre tu sélectionne quoi comme option du coup? Toujours cron? Il y a un message d'alerte pour dire qu'il n'y a rien d'indiqué ou non?
Après le problème ce résout rapidement. Faut que je retrouve la page où j'ai trouvé la solution... A ben voilà :
https://help.nextcloud.com/t/cron-php-hangs-causing-100-cpu-load/116758/3
A savoir que certains parlent de bookmark, mais depuis le temps il doit avoir été mis à jour, donc je doute que ce soit lui la cause... Après mon installation d'origine date un peu aussi.
Nicosss
Tout à fait, tu sélectionnes Cron de la même manière.
Je n'ai pas trop compris ta dernière question par contre. Je pense que c'est pas rapport à la gestion de la tâche cron, il me semble de mémoire que tu as une alerte effectivement si elle ne s'effectue pas.
VINDICATORs
Je n'ai pas regardé sur quoi ce base la détection. D'où ma question. Mais bon tu semble bien y répondre.
Mais bon cela n'enlève pas que cette astuce peut être utile. Ce qui m'étonne, c'est que cela date un peu et toujours pas de nouvelle pour résoudre ce problème.
VINDICATORs
Bon je viens de mettre le cron dans le timer systemd.
Par contre au final... cela revient au même de ce que j'ai fais en crontab...
Cela semble bon, je peux surveiller que le process ne parte pas en sucette bien plus facilement :
antbel
Re:
N'oublions jamais, que nous travaillons sur une version de développement et que les items testés ne seront peut-être jamais validés.
Actuellement, je travaille sur les partages NFS et la sécurité (firewallid, ufw,,etc...) entre différents O.S Linux (famille Red Hat, Debian,etc...) et "Microsoft". Et le wiki Fedora est "has been" , on verra plus tard si je trouve une solution pérenne
Car la variabilité d'ouverture des ports pour chaque session est "a big problème" si on veut garder le caractère variable d'ouverture des ports de NFS même avec autofs.
Car le wiki , où autres sources d'info et malgré les man succincts, c'est galère!!!!
Que " La Force soit avec vous".
VINDICATORs
Parce que les stables sont plus stable???
Retrouver les mêmes bogues sur des rhel centos 10 ans après... c'est pas glorieux et je parle pas côté Ms windows...
Enfin bon la problématique ici avait une solution simple. Encore plus simple en passant sur du "plus moderne" qui... fait la même chose... mais en plus de lignes ...
Pour le wiki si personne ne mets à jour ou ne complète faut pas trop se plaindre...
Nous sommes bénévoles qui avons une vie à côté...
Même en pro j'ai pas le temps de faire les miennes... on me bip tous le temps et les journées ne sont pas à rallonges...
Nicosss
antbel wrote:Re:
N'oublions jamais, que nous travaillons sur une version de développement et que les items testés ne seront peut-être jamais validés.
Actuellement, je travaille sur les partages NFS et la sécurité (firewallid, ufw,,etc...) entre différents O.S Linux (famille Red Hat, Debian,etc...) et "Microsoft". Et le wiki Fedora est "has been" , on verra plus tard si je trouve une solution pérenne
Car la variabilité d'ouverture des ports pour chaque session est "a big problème" si on veut garder le caractère variable d'ouverture des ports de NFS même avec autofs.
Car le wiki , où autres sources d'info et malgré les man succincts, c'est galère!!!!
Que " La Force soit avec vous".
Tu peux développer tes propos, car des commentaires pour faire du chiffre ça n'a pas grand intérêt pour le sujet.
VINDICATORs
Bon... Et bien toujours le même bogue... La commande cron lancé même avec systemd est dans les choux.
Et donc rajout d'un RuntimeMaxSec=360s dans le .service...
Donc le problème est bien dans le script qui part en sucette.
Nicosss
VINDICATORs wrote:Bon... Et bien toujours le même bogue... La commande cron lancé même avec systemd est dans les choux.
Et donc rajout d'un RuntimeMaxSec=360s dans le .service...
Donc le problème est bien dans le script qui part en sucette.
Je n'ai aucun souci de mon côté... Tu ne retrouves rien de plus précis dans les différents logs ?
Tu utilises Bookmarks ?
https://github.com/nextcloud/bookmarks/issues/1548
VINDICATORs
Oui j'utilise bookmark. J'ai vu le problème avec., mais il semble que ce soit de l'histoire ancienne.
Pour les logs j'ai surtout cela :
"message":"/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0","version":"24.0.2.1"}
Qui revient souvent..
Pour les logs je ne vois rien d'autres, j'utilise php-fpm et du coup je n'ai pas de log php seule.
Nicosss
Tu avais bien appliqué les préconisations de maintenance des bases de données lors des mises à jour ?
VINDICATORs
Cela fait des années que cette installation tourne sans autres soucis.
Je fais un check et un repair régulièrement à chaque mise à jour en version stable.
Le souci est peut être que d'anciens fichiers soient la cause, mais bon je ne vais pas m'amuser à refaire l'installation alors que j'utilise la version stable. Surtout vu comment tourne le serveur (aux petits oignons d'ailleurs...).
Comme je ne semble pas être le seule à avoir eu ce problème, j'ai voulu partagé l’expérience en français.
Je passe le serveur en Fedora 36 définitivement ce week end, à voir si ce que j'avais vu sur ma VM ce confirme...
Après j'ai fais pas mal de modifications des fichiers de configuration au fil du temps. Le souci provient peut être de là aussi. A voir ce que cela donne en les désactivant.
Je pense que je vais récupérer le script du cron d'une version plus récente directement. Il est possible qu'il y ai quelques points obsolète...
VINDICATORs
L'upgrade de Fedora 35 vers la 36 s'étant faite dans la douleur (il semble qu'il y ai eu un souci avec l'update de nextcloud en lui même et le cryptage/décryptage des fichiers... Il ne décrypte rien et il manque le module pour le configurer...), je laisse de coté les tests prévu avec les fichiers et autres...
Rien de grave tout les fichiers sont sauvegardés et la DB aussi. Mais bon je me demande si je ne vais pas refaire mon installation de zéro histoire de repartir sur une bonne base (l'ancienne installation date de Nextcloud 17 si mes souvenirs sont bon).
Comme j'ai sauvegardé les fichiers/conf et DB, cela confirmera ou non que le problème vient bien de Nextcloud ou de l'upgrade de Fedora 36.
Même si l'erreur suivante me choque un peu :
[ 368.229885] traps: php-fpm[8045] general protection fault ip:7f3e1651d10c sp:7fffe3b2a400 error:0 in opcache.so[7f3e16512000+b9000]
VINDICATORs
Bon il semble que ce soit une conf qui est HS. A voir laquelle, une installation fraîche de nextcloud retourne le même problème même sans reconfiguration...
J'ai remis le cron directment le temps de résoudre le problème...