Cette nuit, une instance Simplicité est partie à 100% de CPU. Aujourd’hui, des utilisateurs ont rapporté ne plus pouvoir se connecter à l’instance. L’équipe d’exploitation a alors arrêté l’instance via une commande “sim stop”, puis démarré via un “sim start”. Le process Tomcat ne s’est pas lancé (ps -aux = pas de process) mais le SIM indiquait l’instance dans l’état “processing”. Dès lors, il n’était plus possible de démarrer l’instance !
L’équipe d’exploitation a alors édité l’état de l’instance dans le fichier /var/simplicite/data/apps.db pour la passer de “processing” à “stopped”, ce qui a permis de relancer l’instance.
Questions:
en l’état actuel des choses, la procédure suivie pour relancer l’instance est-elle la bonne?
est-il possible de faire évoluer le SIM afin d’éviter la désynchronisation entre l’état réel d’une instance Simplicité et l’état connu par le SIM, ou à défaut de forcer le redémarrage d’une instance restée bloquée dans l’état “processing”?
Le fait que l’instance reste en état “processing” est volontaire, c’est pour bloquer toute autre opération en attendant l’analyse précise du pb rencontrée par l’instance (et le cas échéant la restauration via ses dernières sauvegardes sans risquer que celles ci soient écrasées par d’autres opérations)
Mais effectivement la manière de sortir de cet état “processing” n’est pas idéale, on verra si on peut ajouter un mode “force” sur le sim start/stop qui ignore cet état (ou une action ad hoc)
Mais dans tous les cas cela restera une opération manuelle explicite à ne faire qu’une fois qu’on a investigué, compris et corrigé le pb rencontré.