Problèmes connus

Les problèmes suivants ont une incidence sur le fonctionnement de Sun Cluster 3.0 12/01. Pour connaître les toutes dernières informations, consultez le document Sun Cluster 3.0 12/01 Release Notes Supplement publié en ligne, à l'adresse http://docs.sun.com.

Bogue nº : 4419214

Récapitulatif du problème : le fichier /etc/mnttab n'indique pas l'état largefile actuel d'un système de fichiers VxFS monté globalement.

Solution : utilisez la commande fsadm, plutôt que l'entrée /etc/mnttab, pour vérifier l'état largefile du système de fichier.

Bogue nº : 4449437

Récapitulatif du problème : l'option Global VxFS semble allouer davantage de blocs de disques à une taille de fichier donnée que ne le fait l'option Local VxFS. Vous pouvez le constater à l'aide de la commande ls -ls.

Solution : démontez et remontez le système de fichiers. Les blocs de disques alloués supplémentaires sont éliminés.

Bogue nº : 4490386

Récapitulatif du problème:lorsqu'une grappe utilise des serveurs Sun Enterprise 10000, ceux-ci ont tendance à ne plus savoir comment se comporter lorsque les cartes E/S sont configurées d'une telle façon.

Solution:n'installez pas de cartes E/S UDWIS dans l'emplacement 0 d'une carte E/S SBus de serveurs Sun Enterprise 10000 en grappe.

Bogue nº : 4492010

Récapitulatif du problème : dans une grappe à N noeuds configurée avec N gestionnaires d'interaction, si vous arrêtez ou interrompez le noeud de grappe qui exploite un gestionnaire d'interaction (IM) utilisé par un client, la session du ou des clients s'interrompra. Les tentatives de reconnexion dudit client à un autre IM seront très longues. Ce problème est lié au produit BroadVision. Les techniciens de Broadvision tentent d'y remédier. BroadVision ne prend pas en charge la reprise sur panne de session IM.

Solution : dans un navigateur Netscape, cliquez sur le bouton Stop/Reload (arrêter/recharger), puis cliquez sur le bouton Start Broadway Application. La connexion au serveur BroadVision devrait être immédiate. Cette solution de remplacement fonctionne la plupart du temps pour de nouvelles connexions, quand le noeud IM a été interrompu. Le pourcentage de réussite est moindre, si vous appliquez cette procédure avant d'interrompre le noeud IM. En cas d'échec, videz le cache du disque et le cache mémoire de Netscape.

Bogue nº : 4493025

Récapitulatif du problème:dans une grappe à deux noeuds, si vous commutez oracle-rg du noeud 1 au noeud 2, trois tentatives sont nécessaires avant que BroadVision One-To-One parvienne à enregistrer un nouvel utilisateur. La première tentative donne lieu au message Fail to create new user. La seconde tentative affiche les informations de copyright. La troisième tentative aboutit sans problème. Ce problème survient sur les grappes à N noeuds qui exploitent une base de données Oracle de secours, dans ou hors de la grappe, ainsi que sur les grappes à deux noeuds où le noeud 1 est le noeud principal de http, oracle, roothost, backend et backend2 et où le gestionnaire d'interaction (IM) opère à la demande.

Le problème se résume à l'absence de publication du nom du nouvel utilisateur sur la page d'accueil, une fois la connexion établie. Il s'agit d'un problème connu imputé à BroadVision One-To-One. BroadVision One-To-One connaît ce problème et tente d'y remédier : BVNqa20753.

Solution: il n'y a pas de solution pour l'instant. L'enregistrement de l'utilisateur intervient au bout de trois tentatives.

Bogue nº : 4494165

Récapitulatif du problème:le correctif 110435-05 pour VERITAS File System change le paramétrage de journalisation par défaut de mount_vxfs de l'option log à l'option delaylog. La journalisation est indispensable à la prise en charge de VxFS par Sun Cluster.

Solution:ajoutez manuellement l'option log à la liste des options de VxFS dans le fichier vfstab.

Bogue nº : 4499573

Récapitulatif du problème:si vous utilisez des services de données aux E/S intensives, configurés sur un grand nombre de disques de la grappe, le temps de réponse des services de données risque d'être plus long que prévu, en raison des tentatives infructueuses au niveau du sous-système E/S.

Solution:augmentez la valeur d'extension de ressources de vos services de données en face de Probe_timeout. Contactez votre représentant technique si vous ne parvenez pas à estimer la valeur de temporisation.

# scrgadm -c -j resource -x Probe_timeout=valeur_temporisation

Bogue nº : 4501655

Récapitulatif du problème:Record locking ne fonctionne pas correctement lorsque le périphérique à verrouiller est un périphérique global (/dev/global/rdsk/d4s0). Toutefois, record locking fonctionne correctement lorsque le programme s'exécute plusieurs fois en coulisses sur un noeud donné. Une fois que la première copie du programme a verrouillé une portion du périphérique, il faut que d'autres copies du programme attendent en bloc (block waiting) que le périphérique soit déverrouillé. Cependant, lorsque le programme tourne sur un autre noeud que celui indiqué, il verrouille le périphérique de nouveau alors qu'il devrait attendre en bloc (block waiting) que le périphérique soit déverrouillé.

Solution:il n'y a pas de solution pour l'instant.

Bogue nº : 4504311

Récapitulatif du problème:lors du passage au logiciel Solaris 8 10/01 (obligatoire pour la mise à niveau de Sun Cluster 3.0 12/01) dans une configuration Sun Cluster, les scripts Apache de début et de fin sont restaurés. Si un service de données Apache figure déjà sur la grappe avec sa configuration par défaut (le fichier /etc/apache/httpd.conf existe et le fichier /etc/rc3.d/S50apache n'existe pas), Apache démarre de lui-même. Ceci empêche le service de données Apache de démarrer alors que Apache tourne déjà.

Solution:procédez comme suit sur chaque noeud.

1. Avant d'arrêter un noeud que vous souhaitez mettre à niveau, voyez si les liens suivants existent et, si c'est le cas, si les noms de fichiers comportent un K ou un S majuscule.

   /etc/rc0.d/K16apache /etc/rc1.d/K16apache /etc/rc2.d/K16apache /etc/rc3.d/S50apache /etc/rcS.d/K16apache

   Si ces liens existent et qu'un K ou un S majuscule figure dans le nom de fichier, vous n'avez rien à faire de plus. Sinon, poursuivez avec l'étape suivante, une fois que le logiciel Solaris 8 10/01 est installé sur le noeud.

2. Une fois que le logiciel Solaris 8 10/01 est installé sur le noeud, mais avant de réinitialiser le noeud, mettez de coté les liens Apache restaurés en insérant un k ou un s minuscule dans les noms de fichiers.

   # mv /a/etc/rc0.d/K16apache /a/etc/rc0.d/k16apache # mv /a/etc/rc1.d/K16apache /a/etc/rc1.d/k16apache # mv /a/etc/rc2.d/K16apache /a/etc/rc2.d/k16apache # mv /a/etc/rc3.d/S50apache /a/etc/rc3.d/s50apache # mv /a/etc/rcS.d/K16apache /a/etc/rcS.d/k16apache

Bogue nº : 4504385

Récapitulatif du problème:si vous avez utilisé la commande interactive scinstall(1M), qui confère à la grappe des fonctions de détection automatique des adaptateurs de transport, le message d'erreur suivant risque d'apparaître en cours de sondage :

scrconf:  /dev/clone: No such file or directory

Ce message d'erreur peut occasionner un abandon du sondage et l'échec de la recherche automatique. Il est possible que le périphérique ne soit pas un adaptateur de réseau. /dev/llc20, par exemple. Si vous rencontrez ce problème, demandez à votre représentant technique d'actualiser le compte-rendu des bogues en y ajoutant des informations qui pourraient permettre de reproduire le problème.

Solution:réinitialisez le noeud et recommencez scinstall. Si le problème persiste, sélectionnez les options sans recherche automatique de scinstall.

Bogue nº : 4505391

Récapitulatif du problème:lorsque vous procédez à la mise à niveau du logiciel Sun Cluster, de Sun Cluster 2.2 à Sun Cluster 3.0 12/01, à l'aide de la commande scinstall -u begin -F, la commande scinstall ne parvient pas à supprimer les correctifs avec dépendances et abandonne la procédure en affichant les messages suivants :

scinstall:  Failed to remove patch-id.rev
scinstall:  scinstall did NOT complete successfully!

Cet échec est dû à la dépendance d'un correctif.

Solution:retirez manuellement les dépendances des correctifs, puis reprenez la procédure de mise à niveau. Identifiez, dans le fichier journal, les dépendances des correctifs ayant entraîné l'échec du script. La commande showrev permet également d'identifier les dépendances des correctifs.

showrev -p | grep id_correctif

Bogue nº : 4509832

Récapitulatif du problème:lorsque le tableau CCR (Cluster Configuration Repository) d'une grappe n'est pas valide, il est verrouillé en lecture comme en écriture. Si vous exécutez la commande ccradm -r -f sur le CCR non valide, ce dernier devient accessible en lecture comme en écriture. Cependant, après l'exécution de la commande ccradm -r -f, le tableau CCR reste protégé en écriture.

Solution:réinitialisez toute la grappe.

Bogue nº : 4511478

Récapitulatif du problème:lors de la seconde exécution de la commande interactive scinstall(1M) sur le même répertoire JumpStart, en vue de la configuration d'un serveur JumpStart pour l'installation d'une grappe, il arrive que les noms de la grappe et du répertoire disparaissent. Les deux noms manquent dans la ligne de commande scinstall appelée par ce processus.

Solution:supprimez le fichier .interactive.log.3 du répertoire JumpStart, puis réexécutez scinstall.

Bogue nº : 4515780

Récapitulatif du problème:les fichiers NLS pour Oracle 9.0.1 ne sont pas rétro-compatibles avec les logiciels Oracle 8.1.6 et 8.1.7. Le correctif 110651-04 est erroné.

Solution:supprimez le corerctif 110651-04 et remplacez-le par 110651-02.

Bogue nº : 4517304

Récapitulatif du problème:si syslogd échoue et que vous ne parvenez pas à le redémarrer sur un noeud de grappe (en raison du bogue 4477565, par exemple), rgmd risque de rester en suspens sur un ou plusieurs noeuds. A leur tour, il est possible que d'autres commandes, comme scstat(1M) -g, scswitch(1M) -g, scrgadm(1M) et scha_*_get(1HA,3HA) restent également en suspens et entravent la reprise sur panne de groupes de ressources.

Solution:éditez le script /etc/init.d/syslog, en y insérant une ligne pour supprimer le lien symbolique /etc/.syslog_door qui précède la commande qui débute par /usr/sbin/syslogd. Ligne insérée :

rm -f /etc/.syslog_door

Bogue nº : 4517875

Récapitulatif du problème:après l'installation des modules RSM (Remote Shared Memory) et du module SUNWscrif (module RSMAPI Path Manager), certains chemins empruntés par l'interface RSMAPI ne parviennent pas à l'état RSM_CONNECTION_ACTIVE. Si vous videz la structure topologique à l'aide de rsm_get_interconnect_topology (3rsm), l'interface {rsmapi.h} présente l'état de chaque chemin.

Appliquez la procédure corrective en procédant chemin par chemin, pour ne pas isoler le noeud de la grappe.

Solution:exécutez les commandes suivantes sur les noeuds de la grappe pour détecter les chemins dont l'état diffère de RSM_CONNECTION_ACTIVE (3).

# scconf -c -m endpoint=noeud:adpname,state=disabled
# scconf -c -m endpoint=noeud:adpname,state=enabled

noeud:adpname

Une extrémité du chemin affecté par ce problème

Bogue nº : 4522648

Récapitulatif du problème: à compter de la version 3.1.1 de VxVM, le chemin de la page de manuel est /opt/VRTS/man. Ce même chemin était /opt/VRTSvxvm/man, dans les versions précédentes. Ce nouveau chemin ne figure pas dans le document Guide d'installation du logiciel Sun Cluster 3.0 12/01.

Solution:pour VxVM version 3.1.1 et suivantes, ajoutez /opt/VRTS/man au MANPATH sur chaque noeud de la grappe.