redémarrage en boucle du cron daemon, du coup, le fichier log grossit beaucoup (plusieurs giga)
auriez vous des pistes sur comment je dois attaquer le problème?
simplicite 5.3.15
[/details]
errreur cron.bmp (1.5 MB)
Bonjour
La première chose à faire est de vous mettre à jour sur la révision courante de la 5.3 = la 5.3.19 à date.
Si le problème est toujours présent, il faudra commencer par essayer de cerner quelle(s) tache(s) provoquent le NPE en les inhibant une par une, en commençant par vos tâches spécifiques s’il y en a.
En fonction on pourra investiguer plus avant.
PS: Merci aussi de nous fournir un health check complet (disponible sur /health) pour qu’on puisse avoir une idée plus précise de votre environnement technique.
merci, je n’ai pas toujours la possibilité d’être en dernière version mais je fais des mise à jour les plus régulières possible.
health :
[Platform]
Status=OK
Version=5.3.15
BuiltOn=2023-09-22 16:54
Git=5.3/662de91d19355d80e24aa899086313aba4159d89
Encoding=UTF-8
EndpointIP=XXX.XXX.XXX.XXX
EndpointURL=http://XXXXX-XXXXXXXXX:8080
TimeZone=Europe/Paris
SystemDate=2023-10-19 15:46:21
[Application]
ContextPath=
ActiveSessions=136
TotalUsers=1243
EnabledUsers=1096
LastLoginDate=2023-10-19 15:46:21
[Server]
ServerInfo=Apache Tomcat/9.0.65
ServerType=WEB
ServerActiveSessions=143
ServerSessionTimeout=30
CronStarted=true
[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-1127.19.1.el7.x86_64
SystemEncoding=UTF-8
[Disk]
DiskFree=47749
DiskUsable=47749
DiskTotal=51175
[JavaVM]
Version=11.0.17
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=11.0.17+8-LTS
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=1321225
HeapSize=5353472
HeapMaxSize=20971520
TotalFreeSize=16939273
[Cache]
ObjectCache=4800
ObjectCacheMax=10000
ObjectCacheRatio=48
ProcessCache=4800
ProcessCacheMax=10000
ProcessCacheRatio=48
APIGrantCache=1
APIGrantCacheMax=1000
APIGrantRatio=0
[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=13.9
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.5.0
DBDate=2023-10-19 15:46:21
DBDateOffset=0
DBPatchLevel=5;P03;fd4e397262b1ad3869587cc66f57be0c
UsingBLOBs=true
[Healthcheck]
Date=2023-10-19 15:46:21
ElapsedTime=20
Entre la 5.3.15 et l’actuelle 5.3.19 il y a eu ~140 commits dont beaucoup de correctifs y compris des correctifs de sécurité. Je ne vois rien de directement lié à la cron (cf. la release note), mais ça reste néanmoins toujours une bonne approche de d’abord vérifier si un pb est toujours présent dans la révision à jour car parfois des choses peuvent être indirectement liées…
Par acquis de conscience je viens de faire le test avec une 5.3.15 “out of the box” déployée sur PostgreSQL 13 à jour (13.12) et je ne constate pas le symptôme indiqué sur la cron. Y compris après plusieurs relances manuelles de cette cron
Je pense qu’il faut donc procéder par élimination comme indiqué précédemment pour cerner la ou les tâches qui posent pb.
Ne pas oublier de recharger explicitement la cron après chaque modification du flag “Actif” d’une tâche.
PS: je vois que votre Tomcat 9.0.65 est lui aussi plutôt ancien (juillet 2022), j’en déduis que vous n’utiliez pas nos images Docker car l’image de la 5.3.15 est livrée avec un Tomcat 9.0.80 (celle de la 5.3.19 étant livrée avec le tout dernier Tomcat 9.0.82). Il faudrait aussi prévoir d’upgrader régulièrement Tomcat car il a eu de nombreux correctifs depuis 1 an, notamment ces derniers temps sur diverses vulnérabilités de sécurité.
PS: Après verification dans le code Simplicité 5.3.15, à l’endroit où est généré le message d’erreur “CronDaemon has stopped abnormally” on passe bien l’exception au logger. Cela signifie que vous devriez avoir le stacktrace complet de ce NPE dans les logs Simplicité (dans <tomcat root>/webapps/ROOT/WEB-INF/log) sauf si vous avez modifié la configuration du logger Log4J. Avec ce stacktrace on pourrait voir précisément où il se produit.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
