PLANISWARE – Problèmes récurrents – non démarrage des intranets.
Le client lourd étant amené à disparaitre (à partir de Planisware V6), l’Intranet Server permettant l’accès en « client léger » prend de plus en plus d’importance. Les causes d’un non démarrage des services intranet sont diverses et variées. Dans cet article, nous allons réaliser une check-list des causes les plus courantes de non démarrage des services Intranet.
Saturation du stockage de la BDD
Le redémarrage des intranets intervenant souvent après le rechargement des données de la base (ex. un dump sous oracle), le premier élément de notre check-list concerne l’espace le pourcentage d’espace de stockage libre dans la BDD. Par exemple sous oracle on peut vérifier que les tablespaces (données et système) ne sont pas pleins à plus de 98%. Dans le cas contraire, le volume des données importées était trop volumineux. Dans ce cas il est aussi probable qu’il ne se soit pas importé totalement, ce qui peut bloquer le lancement des intranets. A noter que l’intranet peut également démarrer même avec un dump partiellement importé tant que les données manquantes ne sont pas nécessaires au démarrage (ex. W7_LOGS). Sous oracle, bien que la fonction d’autoextend des tablespaces soit déconseillée, si vous avez cette option, vérifiez également la taille de votre filesystem afin d’être sûr que les datafiles (.dbf) stockant les données du tablespace pourront bien s’agrandir sur la partition du disque.
La commande pour afficher la taille des filesystem sous UNIX est la suivante : « df –g »
Patchs noyau
Lors de montée de version d’une application sous Planisware, il peut arriver d’oublier de mettre à jour la configuration de patchs noyau ou « updates » sur le serveur applicatif hébergeant les services intranets. Vérifiez bien que votre database.ini pointe bien sur le bon dossier d’update (celui de la version en cours). Vérifiez également que les droits sur le dossier et sur les fichiers *.obin sont corrects.
Afin de gagner en lisibilité je vous conseille d’utiliser les liens symboliques pour gérer les différentes configurations de patchs noyau. Il s’agit de conserver dans les fichiers *.ini la référence vers une cible « updates » mais que le répertoire « updates » soit remplacé par un lien symbolique pointant vers un dossier contenant les patchs de la version à jour.
Exemple : update -> update_5.3.2.7 Créer un lien symbolique
La commande associée est la suivante : ln -s DESTINATION SOURCE
Mémoire vive (RAM)
Lors du démarrage la consommation RAM augmente fortement. La commande « top » permet d’afficher la mémoire vive présente sur le serveur, ainsi que la mémoire utilisée. Si celle-ci est insuffisante au lancement, l’intranet ne démarrera pas, ou avec un délai beaucoup plus long (dans le cas où le système possède un SWAP suffisant).
Espace disque
Les intranets risquent également de ne plus fonctionner s’il n’y a pas suffisamment de place pour les logs. La taille d’un fichier de logs est variable en fonction du nombre d’utilisateurs et de la fréquence d’utilisation. Cependant, en moyenne chaque fichier peut contenir 20 mo de log par intranet et par jour. Il convient alors d’aménager un espace disque suffisant et des traitements automatisés de suppression de log quotidiens.
Port déjà occupé par un autre processus
Il est possible qu’un port de l’intranet soit déjà utilisé par un autre processus (externe à Planisware). Par exemple, le port 8400 occupé par un port du système d’exploitation ou d’une autre appli. Pour gérer cela je vous invite à consulter cet article : Conflits entre les ports utilisés par les processus P5 et des processus système.