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...
Nicosss
Tu n'arrives pas à faire une installation de Nextcloud fonctionnelle dans F36 ?
VINDICATORs
Sur une VM nouvellement installé ça passe sans problème.
Par contre même une réinstallation sur mon serveur fait que cela ne fonctionne pas.
Plantage diverses, pdf illisible, fichier txt non décrypté...
Je soupçonne donc soit des paquets manquants (possible), soit une conf qui provoque l'erreur.
Nicosss
Oka c'est plus clair et ça me rassure.
En effet il y a potentiellement une vieille configuration qui traine. Par contre pour trouver le coupable ça va être coton.
Mais en tout en cas une réinstallation ne ferait pas de mal on dirait. Et toi qui trouvait que ça ronronnait, tu vas être surpris du potentiel en latence :-D
VINDICATORs
L'installation d'origine date de plus de 4 ans... Même si j'ai effectué une réinstallation du système une fois depuis, le reste c'est beaucoup de récupération (conf php, httpd, autres). J'en profiterai pour revoir tout cela en profondeur il y a sans doute des options obsolètes dans le lot.
Pour Nextcloud je peux repartir sur une installation fraîche vu qu'il ne faudra que du temps pour réimporter les fichiers. Le reste se reconfigure rapidement.
Ce qui me casse un peu les pieds c'est que j'ai un miroir fonctionnel ailleurs que j'ai coupé le temps de finir d'avoir un réseau potable en voix montante (c'est déjà le cas en descendant).
Le plus pénible c'est de devoir refaire tout le travail sur les optimisations et la sécurité 🙁 . Mais bon rien d'insurmontable non plus.
Enfin bref je fermerai le sujet si cela résout le souci avec le cron.php de nextcloud au passage, même si cette astuce peut resservir dans d'autres domaines.
VINDICATORs
Bon plus je creuse plus je m'enfonce 🙁 .
Du coup je vais arrêter mes recherches vu qu'en plus j'ai planté les accès au serveur...
Il semble que le problème soit la configuration d'un module (sécurités ou autres), car j'ai l'ip du routeur en retour quand je demande un téléchargement avec un beau plantage.
Cela ne provient pas de nextcloud, car même avec une installation vierge sans configuration particulière le problème est le même. Et comme je ne le reproduit pas sur une VM de test vierge en dehors de l'installation de nextcloud... Autant en profiter pour refaire le serveur en grande partie.
Voir sans doute la confirmation qu'il reste une "vieillerie" qui fait que ce n'est pas compatible... Mais je n'arrive pas à mettre la main dessus.
Nicosss
De toute manière, au bout d'un moment il vaut mieux repartir d'une base saine.
C'est pour ça qu'il faut toujours se tenir de la doc à jour et faire ça tranquillement.
VINDICATORs
Bon... J'avais oublié de dé-commenter une ligne dans les réglages de openssl.
En cherchant j'ai activé ceci dans /etc/ssl/openssl.conf :
[provider_sect]
default = default_sect
legacy = legacy_sect
##
[default_sect]
activate = 1
##
[legacy_sect]
activate = 1
Et je retrouve tous mes fichiers décrypté et tout.
Donc il y a bien un souci de ce coté là... A suivre.