Bonjour,
nous avons un problème de visibilité d’instance(Exploitation->plateforme instance : aucune instance visible) sur notre environnement de production, cela induit un problème du cronManager qui s’arrête anormalement et redémarre en boucle tous les millièmes de seconde. Cela fait grossir les logs du serveur de plusieurs Go à l’heure.
Nous avons un environnement de Pré-production qui a la même configuration qui n’a pas de problème de visibilité d’instance. Notre production actuel est une copie de notre pré-production avec export de la base de données et import des mêmes modules dans simplicite.
Avez-vous de la documentation sur les End-points ? comment sont-ils calculés ? ETC.
Avez-vous une idée de l’origine du problème ?
Technical information
Simplicité logs
2024-01-29 00:00:02,780|SIMPLICITE|ERROR||http://instance1:8080||ERROR|system|com.simplicite.util.engine.CronManager$CronDaemon|run||Exception:null||CronDaemon has stopped abnormally
java.lang.NullPointerException
2024-01-29 00:00:02,780|SIMPLICITE|INFO||http://instance1:8080||INFO|system|com.simplicite.util.engine.CronManager$CronDaemon|run||CronDaemon has been restarted
Si vous avez fait une copie de base entre la pre-prod et la prod, il convient de purger tout le paramétrage qui référence vos instances en base.
Liste des Nodes
Depuis la UI Operation > Platform nodes supprimer le URL qui sont hors sujets
ou directement via accès SQL delete from m_pf_node
Puis redémarrer du cluster.
Cette table s’alimente toute seule au démarrage des instances.
Il convient de vérifier que les URL enregistrées sont pingables entre nodes.
CRON_LOCK
Ensuite il faut regarder dans la table des paramètres systèmes, si vous avez d’autres mauvaises URL copiées, dans votre cas le CRON_LOCK est surement à supprimer pour qu’un des nodes reprenne la main au démarrage avec un nom correct.
Il faut configurer votre load-balancer en sticky-session sur le JSESSIONID.
Pour qu’une session UI authentifiée soit toujours routée sur le même node pour retrouver sa session Tomcat.
Bonjour,
Le redémarrage ne corrige que temporairement le problème.
Liste des Nodes :
Au démarrage des nodes, nous observons bien les nodes (dans Operation > Platform nodes) des deux machines cependant. Ils disparaissent après un moment. Les trois VM sont pingables entre elles (load-balancer, node1, node2).
CRON_LOCK
Le cron_lock est bien attribué à une des deux machines.
Sticky-session
Le load balancer est déjà configuré avec le paramètre JSESSIONID.
Merci de fournir les logs qui doivent dire pourquoi.
Arrêt normal : l’arrêt du listener de servlet Tomcat supprime le node de la base
Ou non pingable par ses copains et éliminé ?
La cron HealthCheck tourne toutes les heures, elle vérifie que les services /ping des instances répondent, sinon elles sont retirées de la base avec une log :
Platform node XXX does not respond and has been removed from m_pf_node
Si le /ping ne répond plus, c’est là qu’il faut chercher.
accès /ping interdit ? timeout http ? 100% cpu ? ou tomcat arrêté ?..
bonjour,
nous somme sur un environnement de production l’arrêt des machines sont fait normalement.
le cron Healthcheck s’exécute bien sans erreur, nous n’avons pas de log du type “Platform node XXX does not respond and has been removed from m_pf_node”
le /ping repond bien, pas de timeout, ni de 100%CPU et les tomcat sont bien démarré et accessible via leur IP respectif
les seuls logs disponible que nous avons sont:
2024-02-05 17:55:00,007|SIMPLICITE|WARN||http://plateform2:8080||WARN|system|com.simplicite.util.engine.CronManager|lock||Event: The CRON_LOCK owner http://plateform1:8080 does not respond, try to reassign the CRON_LOCK...
2024-02-05 17:55:00,007|SIMPLICITE|INFO||http://plateform2:8080||INFO|system|com.simplicite.util.engine.CronManager|unlock||Event: Remove the CRON_LOCK
2024-02-05 17:55:01,959|SIMPLICITE|INFO||http://plateform2:8080||INFO|system|com.simplicite.util.engine.CronManager|saveLock||Event: Acquire the CRON_LOCK = http://plateform2:8080-1779739858-1707126900003
2024-02-05 17:55:01,988|SIMPLICITE|INFO||http://plateform2:8080||ICORECM004|system|com.simplicite.util.CronJob|run||Execute job deadlockTimestamp at 2024-02-05 17:55:01
2024-02-05 17:55:01,988|SIMPLICITE|INFO||http://plateform2:8080||INFO|system|com.simplicite.util.engine.CronManager|run||Event: Next cron job: HealthCheck at Mon Feb 05 18:00:00 CET 2024
2024-01-29 00:00:00,000|SIMPLICITE|ERROR||http://plateforme1:8080||ERROR|system|com.simplicite.util.engine.CronManager$CronDaemon|run||Exception:null||CronDaemon has stopped abnormally
java.lang.NullPointerException
2024-01-29 00:00:02,619|SIMPLICITE|INFO||http://plateforme1:8080||INFO|system|com.simplicite.util.engine.CronManager$CronDaemon|run||CronDaemon has been restarted
à 17h55, il fait un http://plateform1:8080/ping (sur celui qui a le CRON_LOCK)
Il ne répond pas (pas de réponse / ou timeout de 5 secondes / ou réponse non 200)
donc plateform2 reprend le lock pour traiter les jobs uniques
Le /ping peut fonctionner par ailleurs, il faut voir si ça correspond à un pic de charge ou une autre opération sur plateform2 vers 18h (historique des arrêt/relance… ? charge monitoring ?).
bonjour,
les logs montré ne sont qu’un aperçu, il y a des pic de charge mais qui ne dépasse pas la capacité du serveur(max 70% du cpu et 40% de ram).
Pour le NPE nous n’avons pas de stacktrace de l’erreur en question dans le fichier simplicite.log ni dans le catalina.out.
L’erreur est en boucle qui rempli notre fichier de log de plusieurs Go à l’heure.
2024-01-29 00:00:00,000|SIMPLICITE|ERROR||http://plateforme1:8080||ERROR|system|com.simplicite.util.engine.CronManager$CronDaemon|run||Exception:null||CronDaemon has stopped abnormally
java.lang.NullPointerException
2024-01-29 00:00:02,619|SIMPLICITE|INFO||http://plateforme1:8080||INFO|system|com.simplicite.util.engine.CronManager$CronDaemon|run||CronDaemon has been restarted
a minuits il y a juste une historisation des logs.
et pour la question du http sur notre environnement de préProduction les end-points sont rempli de la même façon en http.
Sans log ça va être compliqué d’analyser la cause. Le code qui catche le NPE est pourtant le suivant dans la boucle du daemon :
try {
// boucle de daemon pour dormir et lancer les jobs planfiés
}
catch (Exception | Error e) {
AppLog.error(getClass(), "run", "CronDaemon has stopped abnormally", e, null);
// restart...
}
Cet API AppLog trace bien la stack de l’exception “e” passée en paramètre. Que ce soit des anomalies applicatives (Exception) ou systèmes (Error de plus bas niveau jvm, tomcat, jdbc…).
La stack-trace est peut être filtrée quelque part dans votre config log4J / la façon de remonter les logs ? voyez vous des stack par ailleurs (essayez de forcer un NPE par code dans un try/catch) ? ou alors ce NPE est très bas niveau.
On pourrait mettre un garde fou pour ne pas redémarrer en boucle ce “Retry/NPE” et terminer en FATAL sans restart, mais ça ne solutionnera pas la cause du problème. Vos logs seraient stables mais aucun job planifié ne serait lancé si ce daemon est arrêté.
A minuit, faites vous des opérations sur la base ?
Rien dans les logs fournis ne confirme votre analyse.
Dans vos logs je ne vois que 2 choses :
des “ping” qui ne répondent pas “200” de temps en temps = réaffectation de lock normal
et à minuit pile un NPE de la cron qui se relance automatiquement dans la foulée
comment sont extraits les logs ? où sont passés les stack-traces ?
avez vous ajouté des agents ou autre supervision applicative ou modifié la conf log4j ?
Si la pre-prod n’a pas de soucis, il faut regarder vos différences d’installation / exploitation.
Arret / relance
Sauvegarde à chaud ou à froid
Disponibilité de la base
etc
De notre point de vue Simplicité se comporte normalement.
Par exemple si la base de données est HS, il y aura des logs d’erreurs à chaque requête SQL.
Bonjour,
Après quelque analyse supplémentaire, nous avons une nouvelle piste.
La commande curl hostnamenode1:8080/ping ne fonctionne pas sur notre environnement de PROD et marche sur notre PPROD, le serveur n’arrive pas à résoudre le hostname sur serveur distant. Est-ce que simplicite peut interférer avec la résolution du dns ?
Et concernant les logs qui se remplissent, nous avons un script qui arrête les instances pour effectuer des dumps de la base de données tous les jours à 3h du matin.
Voici une partie du script de redémarrage :
#definition des variables
DATE=$(date +"%m-%d-%Y")
DB_PASSWORD=XXXXXXXXXXXXXX
DB_HOST=127.0.0.1
DB_PORT=5432
DB_NAME=bdname
DB_USER=bduser
DUMPFILE=backup-scenario-$(date +\%Y\%m\%d)
# Arret du apache de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Arret du apache en PRODUCTION"
ssh root@ip-load-balancer "systemctl stop httpd.service"
# Arret des tomcats de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Arret des tomcat en PRODUCTION"
ssh simplicite@ip-node1 "/home/simplicite/tomcat/stop.sh"
echo ""
ssh simplicite@ip-node2 "/home/simplicite/tomcat/stop.sh"
sleep 1m
# Dump de la BDD prod
echo "$DATE à $(date +"%T") : Début de l'export de la base en PRODUCTION"
PGPASSWORD=XXXXXXXXXX pg_dump -h 127.0.0.1 -p 5432 -U simplicite simplicite -Fc -C --schema=public --no-owner --clean > /opt/dump/backup-scenario-$(date +\%Y\%m\%d).dmp
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Fin de l'export"
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Taille du dump"
echo ""
du -sh /opt/dump/*
# Redemarrage du postgres de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Redémarrage de la base en PRODUCTION"
#redémarrage de la base de données prod
systemctl restart postgresql-13.service
# Demarrage des tomcat de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Démarrage des services tomcat en PRODUCTION"
ssh simplicite@ip-node1 "/home/simplicite/tomcat/start.sh"
echo ""
sleep 5m
ssh simplicite@ip-node2 "/home/simplicite/tomcat/start.sh"
# Demarrage du apache de prod
echo ""
echo "------------------------------------------------------------------------------------"
ssh root@ip-load-balancer "systemctl start httpd.service"
Nous pensons que le tomcat ne s’arrête pas correctement. Avez-vous une idée de la cause ?
Est-ce que simplicite peut interférer avec la résolution du dns
Non ni la webapp Simplicité ni Tomcat (ni Java) n’ont d’influence sur les couches sous-jacentes de l’OS ou de ses services.
Si un simple curl http://<hostname>:8080/ping lancé depuis l’endroit où tourne Tomcat n’aboutit pas c’est soit un pb de DNS (le nom <hostname> n’est pas connu à cet endroit) soit un pb de firewall (port 8080 filtré), soit un pb de filtrage web (/ping bloqué), etc…Ca dépend de la nature de l’erreur retournée par le curl => essayez de déterminer quel est le pb de communication que vous rencontrez via des dig <hostname> , nmap -p 8080 <hostname>, etc.
bonjour,
nous avons trouvé le problème de visibilité. La configuration des machines nous empêchait de connaître l’autre machine via un nom de machine.
Cependant, nous avons toujours un problème lie au log qui se remplisse trop vite.
voici un log partiel ci-joint. log_error.log (211.4 KB)
le problème apparait lors d’un redémarrage. avez-vous une idée de l’origine du problème?
Les premiers messages de la log fournies indiquent un pb de connectivité à la base de données. Le reste doit être une conséquence non prévue de cette perte de connexion à la base.
Visiblement ça se passe à 3h du matin. Regardez ce qu’il se passe spécifiquement à cette heure là sur votre infrastructure. Si, par exemple, c’est peut être une heure à laquelle vous “isolez” la base de données pour faire une sauvegarde ?
PS: Indépendamment de ça, pouvez vous nous fournir un health check complet (sur /health) pour qu’on puisse avoir une visibilité précise des composants de votre installation ?
bonjour,
oui, il y a un arrêt à 3 heure pour effectuer une sauvegarde de la base de données.
je vous remet le script qui est exécuté à cette heure ci.
#definition des variables
DATE=$(date +"%m-%d-%Y")
DB_PASSWORD=XXXXXXXXXXXXXX
DB_HOST=127.0.0.1
DB_PORT=5432
DB_NAME=bdname
DB_USER=bduser
DUMPFILE=backup-scenario-$(date +\%Y\%m\%d)
# Arret du apache de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Arret du apache en PRODUCTION"
ssh root@ip-load-balancer "systemctl stop httpd.service"
# Arret des tomcats de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Arret des tomcat en PRODUCTION"
ssh simplicite@ip-node1 "/home/simplicite/tomcat/stop.sh"
echo ""
ssh simplicite@ip-node2 "/home/simplicite/tomcat/stop.sh"
sleep 1m
# Dump de la BDD prod
echo "$DATE à $(date +"%T") : Début de l'export de la base en PRODUCTION"
PGPASSWORD=XXXXXXXXXX pg_dump -h 127.0.0.1 -p 5432 -U simplicite simplicite -Fc -C --schema=public --no-owner --clean > /opt/dump/backup-scenario-$(date +\%Y\%m\%d).dmp
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Fin de l'export"
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Taille du dump"
echo ""
du -sh /opt/dump/*
# Redemarrage du postgres de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Redémarrage de la base en PRODUCTION"
#redémarrage de la base de données prod
systemctl restart postgresql-13.service
# Demarrage des tomcat de prod
echo ""
echo "------------------------------------------------------------------------------------"
echo "$DATE à $(date +"%T") : Démarrage des services tomcat en PRODUCTION"
ssh simplicite@ip-node1 "/home/simplicite/tomcat/start.sh"
echo ""
sleep 5m
ssh simplicite@ip-node2 "/home/simplicite/tomcat/start.sh"
# Demarrage du apache de prod
echo ""
echo "------------------------------------------------------------------------------------"
ssh root@ip-load-balancer "systemctl start httpd.service"
et voici le résultat du health (jai modifier les ip et url ) health.txt (1.4 KB)
OK si vous arrêtez la base de données vous devez à minima aussi arrêter la cron Simplicité (et bien entendu ne rien faire sur l’application : ni accès UI, ni API, ni I/O, …) mais de manière plus sûre vous pouvez aussi d’abord arrêter vos instances Simplicité avant arret de la base, faire l’arret de base de données une fois que vous avez la certitude de l’arret complet de ces instances, puis redémarrer vos instances Simplicité après redémarrage complet de la base. Je pense que votre script, dont ça semble être la logique, ne garantit pas que les process soient bien arrêtés/redémarrés (un simple sleep n’est pas une bonne approche = mieux vaut checker les ports et/ou la réponse du /ping des instances, etc.)
Mais, fondamentalement, si rien ne se passe sur l’application, faire la sauvegarde de la base de données à chaud ne pose pas de pb vis à vis des données métier, ça éviterait de devoir faire un cycle plus compliqué d’arret relance.
Mais sinon une autre approche plus simple et fiable si vous voulez vous assurer à 100% de l’intégrité de votre sauvegarde de base sans faire un arret/relance compliqué = faites comme sur nos instances cloud où nous faisons des sauvegardes de base en suspendant le process Tomcat par un kill -STOP <pid> avant la sauvegarde suivi d’un kill -CONT <pid> après la sauvegarde.
bonjour,
nous avions trouvé une piste pour la correction des log qui se remplisse très vite, mais cela n’a pas eu d’effet, nous avons toujours le problème.
dans les logs catalina nous avons une fuite mémoire :
17-Mar-2024 03:00:03.896 AVERTISSEMENT [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [ROOT] semble avoir démarré un thread nommé [HttpClient-22-SelectorManager] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est :
java.base@11.0.17/sun.nio.ch.EPoll.wait(Native Method)
java.base@11.0.17/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@11.0.17/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
java.base@11.0.17/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)
platform/java.net.http@11.0.17/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:867)
17-Mar-2024 03:00:03.898 AVERTISSEMENT [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [ROOT] semble avoir démarré un thread nommé [HttpClient-23-SelectorManager] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est :
java.base@11.0.17/sun.nio.ch.EPoll.wait(Native Method)
java.base@11.0.17/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@11.0.17/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
java.base@11.0.17/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)
platform/java.net.http@11.0.17/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:867)
17-Mar-2024 03:00:03.898 AVERTISSEMENT [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [ROOT] semble avoir démarré un thread nommé [HttpClient-24-SelectorManager] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est :
java.base@11.0.17/sun.nio.ch.EPoll.wait(Native Method)
java.base@11.0.17/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@11.0.17/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
java.base@11.0.17/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136)
platform/java.net.http@11.0.17/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:867)
17-Mar-2024 03:00:03.899 AVERTISSEMENT [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [ROOT] semble avoir démarré un thread nommé [HttpClient-24-Worker-0] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est :
java.base@11.0.17/jdk.internal.misc.Unsafe.park(Native Method)
java.base@11.0.17/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
java.base@11.0.17/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
java.base@11.0.17/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
java.base@11.0.17/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
java.base@11.0.17/java.lang.Thread.run(Thread.java:829)
17-Mar-2024 03:00:03.900 AVERTISSEMENT [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [ROOT] semble avoir démarré un thread nommé [HttpClient-24-Worker-1] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est :
java.base@11.0.17/jdk.internal.misc.Unsafe.park(Native Method)
java.base@11.0.17/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
java.base@11.0.17/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
java.base@11.0.17/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
java.base@11.0.17/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
java.base@11.0.17/java.lang.Thread.run(Thread.java:829)
17-Mar-2024 03:00:03.900 AVERTISSEMENT [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads L'application web [ROOT] semble avoir démarré un thread nommé [HttpClient-24-Worker-2] mais ne l'a pas arrêté, ce qui va probablement créer une fuite de mémoire ; la trace du thread est :
java.base@11.0.17/jdk.internal.misc.Unsafe.park(Native Method)
java.base@11.0.17/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
java.base@11.0.17/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
java.base@11.0.17/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
java.base@11.0.17/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
java.base@11.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
java.base@11.0.17/java.lang.Thread.run(Thread.java:829)
Avez-vous une idée d’où pourrez venir le problème ?
Pour rappel, le serveur redémarre chaque jour à 3 h, mais le problème apparaît durant le week-end ou il ne se passe rien et ou il n’y pas d’utilisateur.
Les traces que vous avez copié/collé sont des traces Tomcat, pas Simplicité. Elles ne me disent rien mais visiblement elles se produisent lors de votre rédemarrage à 3h du matin, donc il y a sans doute un lien avec la manière dont vous effectuez ce redémarrage (qui est, je pense, aussi la cause de vos pbs de logs d’erreur de connexion à la base de données, cf. mes réponses précédentes)
Si vous tenez absolument à ce rédemarrage nocturne pour sauvegarde, vous devez vous assurer de le faire, d’une manière ou d’une autre, de la manière suivante:
demande d’arret “propre” de Tomcat (ex: via le stop.sh)
attendre que Tomcat soit totalement arrêté (il y a plusieurs manière de s’en assurer en checkant le PID et/ou en testant les ports TCP, …), à défaut faire un arret “violent” (genre kill -9)
faire votre dump de base
démarrer Tomcat (ex: via le start.sh)
Et si vous voulez, en plus, faire un redémarrage du serveur PostgreSQL, il faut vous assurer que celui-ci est est bien totalement démarré avant de démarrer Tomcat.
Cela dit, si la seule justification de ces redémarrages nocturnes c’est de faire un dump intègre, je continue de vous recommander de faire plutôt votre dump “à chaud” en suspendant le process Tomcat le temps du dump via kill -STOP/kill -CONT cela évitera tous les effets de bords liés aux redémarrages .
