Dans cet article


Offres d'emploi

Tags

Conflits entre les ports utilisés par les processus P5 et des processus système

Description du problème

Dans certains cas, lorsque l’on tente de démarrer les services P5 (Apache, Dispatch, Connect, Intranet Server), un service refuse de se lancer en indiquant que le port est déjà utilisé. Cette erreur est embêtante car cela signifie qu’un autre processus est déjà lancé sur le port défini pour l’un des processus P5.

En général on aura une erreur du type suivant dans les logs du master :

Impossible d'ouvrir le port TCP XXXX : Address already in use

Avec XXXX le numéro du port qui pose problème.

Origine

Il s’agit souvent d’un conflit entre un processus système et le service que l’on souhaite lancer. Pour s’en assurer on peut vérifier la valeur du paramètre « ip_local_port_range » du fichier « /etc/sysctl.conf ». En effet cette variable contient la plage de ports utilisables par le système pour ses processus.

Exemple (avec le user root) :

cat <strong>/etc/sysctl.conf</strong> | grep ip_local_port_range

Résultat :

net.ipv4.ip_local_port_range = 8000 65000

Dans l’exemple ci-dessus les ports adressables par les processus système UNIX sont contenus dans la plage de 8000 à 65000. Or par défaut les ports d’une instance Planisware sont les suivants :

  • Apache : 8000
  • Dispatch : 8100
  • Intranet Server de référence : 8400
  • etc…

Dans cet exemple on constate que les ports définis pour le serveur d’application P5 peuvent être utilisés par le système provoquant ainsi un conflit lorsque l’on tente de démarrer les services P5.

Résolution

Pour éviter ce genre de mésaventure il est nécessaire de redéfinir la plage des ports utilisables par le système (par exemple de 14000 à 65000). Pour cela il suffit d’éditer le fichier « /etc/sysctl.conf » avec le user root puis de modifier les valeurs de la plage de ports.

Ensuite il est nécessaire d’appliquer la commande suivante toujours avec l’utilisateur root :

sysctl -w net.ipv4.ip_local_port_range="14000 65000"

Avec « net.ipv4.ip_local_port_range » le nom de la variable Linux correspondant à la plage des ports système.

Note : une fois le service système lancé (celui lancé sur un port P5) il est plutôt risqué de le tuer afin de permettre le lancement des processus P5. La solution la plus simple consiste à redémarrer le serveur Linux pour libérer le(s) port(s).

 

L'équipe AXOPEN

Voir aussi les articles suivants

Supervision des processus Planiware sous UNIX

Supervision des processus Planiware sous UNIX

Le 18/02/2012 par Thibault Gonin

Sous UNIX lorsqu’une instance Planisware (PLW) est démarrée un certain nombre de processus système apparaissent. Chaque module Planisware (Connect, Application Server ou Intranet Server, Dispatch, Timecard etc.) possède un certain nombre de processus et sous-processus qui lui est propre. En exploitation il peut être intéressant de superviser ces processus unix pour détecter une éventuelle défaillance de l’un d’eux. Cet article présente d’une part les processus Planisware présent sur un serveur UNIX et d’autre part les stratégies de surveillance que l’on peut mettre en place pour une supervision efficace.
Lire l'article

Migration des activités d&rsquo;un projet à un autre

Migration des activités d’un projet à un autre

Le 22/11/2012 par Thibault Gonin

Objectif : L’objectif de ce tutorial est de migrer des activités (tâches et/ou sous-projets) d’un projet à un autre, via le client lourd Planisware. Procédure de migration : Ouvrir le projet cible, de réception des activités (appelé ici PROJET_B). Ouvrir le projet d’origine des activités (appelé ici PROJET_A). Chargement des fichiers projet Pour réaliser cette opération on se placera dans la table des activités (accessible depuis le client lourd) ce qui évite les contraintes liés à l’affichage des activités des projets dans les écrans Processes.
Lire l'article

Oracle : impact de l&rsquo;obsolescence du type LONG sur le modèle de données Planisware
Description Le type de données LONG est un type obsolète pour les bases de données ORACLE. Il est encore présent dans les versions récentes d’Oracle pour des raisons évidentes de compatibilité mais il n’évolue plus et est destiné à disparaître à terme. Il est remplacé progressivement par les types CLOB et NCLOB. Cet article présente les impacts de l’obsolescence de ce type LONG sur le produit Planisware ainsi que des stratégies possibles de migration.
Lire l'article