[AIX Solaris HP-UX Linux Windows][IBM i]

Problèmes de démarrage ou de redémarrage du serveur d'applications

Si le processus serveur ne démarre pas ou démarre avec des erreurs, les rubriques suivantes devraient vous aider à diagnostiquer l'incident.

Le programme d'installation s'exécute correctement mais un serveur d'applications ne démarre pas ou démarre avec des erreurs

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.
  • Parcourez les fichiers journaux du serveur d'applications à la recherche d'indications. Par défaut, les fichiers journaux se trouvent dans : Plusieurs applications déployées sur un serveur d'applications ou un noeud peuvent mettre du temps à démarrer. Parcourez régulièrement le SystemOut.log et observez les mises à jour les plus récentes pour voir si le serveur continue de démarrer.
  • [Linux][AIX HP-UX Solaris]La commande tail -f racine_profil/ logs/nom_serveur/SystemOut.log est un moyen pratique d'observer la progression du serveur.
  • Cherchez toutes les erreurs ou avertissements relatifs aux ressources spécifiques avec le module, tel que les modules web, les beans enterprise et les ressources de messagerie. Si vous en trouvez, examinez le fichier de configuration du serveur d'applications pour les paramètres de configuration de cette ressource. Puis redémarrez le serveur pour voir si ce composant est responsable de l'incident.

    [AIX Solaris HP-UX Linux Windows]Par exemple, dans une configuration de base ou non répartie sur des systèmes Windows, parcourez racine_profil\config\cells/ApplicationServerCell\nodes\nom_noeud\servers\nom_serveur\server.xml, et recherchez dans les balises XML les propriétés de cette ressource. Changez sa valeur initialState de START à STOP.

    [IBM i]Par exemple, parcourez racine_profil/config/cells/ApplicationServerCell/nodes/nom_noeud/servers/nom_serveur/server.xml et examinez les balises XML pour les propriétés de cette ressource. Changez sa valeur initialState de START à STOP.

  • Recherchez tout message d'erreur ou d'avertissement dans la table de référence des messages en cliquant sur la vue Référence de l'InfoCenter et en développant Messages dans l'arborescence de navigation.
  • Après la création d'un serveur d'applications, vous devez synchroniser les noeuds avant de sauvegarder les paramètres de configuration du nouveau serveur. Si vous ne synchronisez pas les noeuds, il se peut que votre nouveau serveur ne démarre pas.
    1. Sur la page du serveur d'applications répertoriant tout vos serveurs d'applications, cliquez sur Préférences.
    2. Sélectionnez l'optionSynchroniser les modifications avec les noeuds si elle n'est pas déjà sélectionnée.
    3. Cliquez sur Appliquer puis sur Serveurs d'applications pour revenir à votre liste de serveurs d'applications.
    4. Cliquez sur Sauvegarder pour sauvegarder les paramètres de configuration du nouveau serveur.
  • Si le serveur d'applications fait partie d'une configuration de déploiement réseau ou à plusieurs serveurs,
    • [AIX Solaris HP-UX Linux Windows] Vérifiez que vous avez ajouté le serveur d'applications à la configuration.
    • Vérifiez que la configuration est synchronisée entre le gestionnaire de déploiement et le noeud. Si l'auto synchronisation est activée, attendez la fin de la synchronisation. Si vous effectuez une synchronisation manuelle, demandez une synchronisation pour chaque noeud du cluster.
    • [AIX Solaris HP-UX Linux Windows]Avant de démarrer un serveur d'applications :
      1. Démarrez le processus de gestionnaire de déploiement avec la commande suivante :
      2. Exécutez la procédure qui consiste à fédérer le noeud qu'exécute le serveur d'applications sur le gestionnaire de déploiement. Cette procédure est impérative même s'il n'y a qu'un seul noeud et même si les deux processus se trouvent sur le même serveur physique.
      3. Vérifiez que le gestionnaire de déploiement est actif.
        Puis exécutez la commande addNode nom_noeud à partir du répertoire racine_profil/bin. Par exemple, la commande suivante ajoute le serveur d'applications au gestionnaire de déploiement sur un système Linux ou UNIX :
        addNode.sh localhost 8879 -includeapps -startingport 3333

        Le gestionnaire de déploiement utilise le port SOAP par défaut de 8879. Les deux processus se trouvent sur la même machine. Toutes les applications installées (sauf la console d'administration qui est une application système) sur le serveur d'applications sont installées sur le gestionnaire de déploiement.

        Le paramètre startingport évite l'incident de coexistence avec les processus d'agent de noeud sur une machine. Tous les ports du processus d'agent de noeud commencent au numéro de port 3333. Vous pouvez aussi affecter des ports séparément à l'aide du paramètre portprops.

        Pour plus d'informations, voir la description de la commande addNode.

      4. Démarrez le gestionnaire de noeud hébergeant les serveurs d'applications que vous voulez exécuter en tapant soit racine_serveur_applis/bin/startNode.sh soit racine_serveur_applis\bin\startNode.bat.
    • [IBM i]Avant de démarrer un serveur d'applications, utilisez le script startNode Qshell pour démarrer le processus d'agent de noeud sur les noeuds hébergeant les serveurs d'applications que vous démarrez.
  • Vérifiez que le nom logique que vous avez défini pour apparaître sur la console de votre serveur d'applications ne contient pas de caractères invalides comme : - / \ : * ? " < > et des espaces au début ou à la fin.
  • [AIX Solaris HP-UX Linux Windows]Si vous ne pouvez pas démarrer le gestionnaire de déploiement après une installation réussie, recherchez des messages dans les fichiers racine_profil/logs/nom_serveur/SystemErr.log et SystemOut.log.
  • [IBM i]Si vous ne pouvez pas démarrer le gestionnaire de déploiement après une installation réussie, recherchez des messages dans les fichiers racine_profil/logs/nom_serveur/SystemErr.log et SystemOut.log.
  • Si vous utilisez Apache Derby et recevez une erreur ERROR XSDB6: Une autre instance d'Apache Derby a peut-être déjà amorcé l'erreur de la base de données nomBaseDeDonnées lors du démarrage du serveur d'applications, reportez-vous à la rubrique traitant des incidents liés à l'accès aux données pour obtenir des informations supplémentaires.
  • [AIX Solaris HP-UX Linux Windows]Lorsque vous utilisez un ID utilisateur non root pour exécuter des serveurs d'applications, vérifiez que :
    • L'utilisateur non root dispose de droits en écriture dans le répertoireracine_serveur_applis/temp.
    • La JVM dispose de droits en écriture dans le fichierracine_serveur_app/config/plugin-cfg.xml.
    • L'utilisateur non root a accès au répertoire logs.
  • [IBM i]Lorsque vous utilisez un profil utilisateur différent de QEJBSVR pour exécuter un serveur d'applications, vérifiez que :
    • Le profil utilisateur a un QEJBSVR défini comme son profil de groupe.
    • QEJBSVR possède tous les fichiers et répertoires dans le répertoire racine_profil. Vous pouvez utiliser la commande suivante dans une session Qshell pour définir QEJBSVR comme propriétaire :
      chown -R QEJBSVR racine profil
  • Il se peut que le serveur d'applications ne démarre pas en mode restreint. Vous pouvez configurer un serveur d'applications pour autoriser ou restreindre l'accès aux classes de serveur interne. Par défaut, l'accès est autorisé. Si l'accès est restreint, il se peut que le serveur ne démarre pas. Si le serveur d'applications ne démarre pas en mode Restreindre, modifiez l'accès aux classes internes à Autoriser.

Un message d'erreur peut apparaître dans le SystemOut.log après le redémarrage d'un serveur d'applications

Il se peut que le message d'erreur suivant apparaisse dans le SystemOut.log après le redémarrage d'un serveur d'applications :
La liaison de la socket n'a pas abouti pour l'hôte nom_hôte et le port numéro_port.  Il est possible que le port soit déjà utilisé.

Cet incident peut se produire si le réseau est lent et si l'écoute du port répertorié dans le texte du message n'était pas terminée lorsque l'application a été arrêtée et redémarrée.

Pour vérifier qu'il s'agit de la cause de l'incident, vérifiez l'état du port.

Pour corriger cet incident, attendez quelques minutes après l'arrêt du serveur :
  1. [AIX Solaris HP-UX Linux Windows]Vérifiez qu'aucun port n'est en mode écoute. Utilisez la commande :
    netstat -a 
  2. [IBM i]Vérifiez qu'aucun port n'est en mode écoute. Utilisez cette commande CL :
    NETSTAT *CNN
  3. Redémarrez le serveur

Le message d'exception "DiscoveryService.sendQuery" apparaît dans le fichier journal de FFDC.

Quand vous démarrez un gestionnaire de déploiement, celui-ci tente de reconnaître les agents de noeud configurés dans sa cellule. S'il ne détecte pas les agents de noeud de la cellule, il enregistre une exception dans le fichier journal FFDC (first failure data capture) pour chacun de ces agents. Si les agents de noeud ne sont pas supposés être actifs, vous pouvez ignorer cette exception. Dans le cas contraire, le fichier journal FFDC peut contenir d'autres informations qui vont aideront à déterminer pourquoi le gestionnaire de déploiement ne parvient pas à reconnaître les agents de noeud en dépit du fait qu'ils sont réputés actifs.

[IBM i]

Le serveur ne redémarre pas sous IBM i après l'application de WebSphere Application Server version 8.5.0.1

Si le serveur ne redémarre pas sous IBM i après l'application de la version 8.5.0.1, vous pouvez recevoir le message suivant : "CWWKE0044E: There is no write permission for server directory." (Pas de droit d'accès en écriture sur le répertoire du serveur)

Cette erreur se produit uniquement sous IBM i en cas de démarrage avec l'intégration du système d'exploitation et l'utilisation de l'utilisateur QEJBSVR.

Vous pouvez résoudre ce problème temporairement en encapsulant un appel de la commande de serveur dans un script qui supprime le contenu du répertoire <serverName>/workarea/.sCommandAuth.

Le service de support IBM dispose de documents et d'outils qui peuvent vous aider à collecter plus rapidement les informations dont vous avez besoin pour résoudre votre incident. Avant d'ouvrir un rapport d'incident, consultez la page du service de support :

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_appsrvstart
Nom du fichier : rtrb_appsrvstart.html