Problèmes liés au fichier de vidage principal

Le vidage principal fonctionne correctement si le fichier principal est généré sous le dossier cible, par exemple, /<path_to_the_location>/core, lors d'une panne de serveur. Les étapes pour vérifier cette fonctionnalité sur le système d'exploitation (OS) Linux sont décrites ci-dessous.

Obtenez l'ID de processus du serveur Intelligence en exécutant ps -ef | grep -i mstrsvr. L'ID de processus est 6837 dans l'exemple ci-dessous.

Copier

$ ps -ef | grep -i mstrsvr
mstr      6837     1  2 12:15 ?        00:02:37 /opt/mstr/MicroStrategy/install/IntelligenceServer/bin/MSTRSvr -s -w /opt/mstr/MicroStrategy/IntelligenceServer -t status-iserver.xml /opt/mstr/MicroStrategy/install/lib/libMSTRSvr2.so -n CastorServer
mstr     32481 32391  0 14:12 pts/0    00:00:00 grep --color=auto -i mstrsvr

Simulez une panne de serveur en exécutant une sudo kill -6 <server_process_id> commande.
Vérifiez qu'un fichier core est généré sous le dossier cible. Par exemple, /<path_to_the_location>/core. La taille du fichier principal doit être différente de zéro.

Si le fichier core n'est pas généré selon la procédure ci-dessus, vous devez en identifier la cause première. Les causes possibles et les étapes pour les résoudre sont décrites ci-dessous.

Configuration du système d'exploitation Linux invalide ou manquante

Voir Configuration logicielle requise et recommandations pour obtenir la configuration système d'exploitation correcte pour activer le vidage principal. Assurez-vous de redémarrer Intelligence Server après avoir appliqué les paramètres.

Configuration manquante lorsque Intelligence Server est enregistré en tant que service

Votre machine Linux aura peut-être besoin d'un redémarrage pour appliquer la configuration de vidage de mémoire au niveau du système d'exploitation. Si le core dumping est toujours désactivé après le redémarrage, le profil utilisateur par défaut a peut-être désactivé la création de fichiers core pour les processus lancés lors de la phase d'initialisation (lors du redémarrage de la machine). Pour résoudre ce problème, appliquez les étapes ci-dessous.

À l'aide de root autorisation, ouvrez l' /etc/init.d/mstr-<InstallName>-iserver-CastorServer script d'initialisation. Généralement, <InstallName> est de la forme de user@timestamp. Localisez les lignes suivantes.
Copier
```
start ()
{
```
Sous les lignes localisées, ajoutez la commande suivante pour permettre à Intelligence Server de démarrer en tant que service avec le fichier principal activé.
Copier
```
ulimit -c ulimited
```

Espace disque insuffisant

Vous devez vous assurer que le disque sur lequel le fichier principal sera écrit dispose de suffisamment d’espace libre. Notez que le fichier principal est écrit dans le répertoire spécifié pour kernel.core_pattern (voir Activation du core dump pour plus de détails), tandis que la taille attendue des fichiers principaux est identique à l'empreinte mémoire du serveur Intelligence Server lorsqu'il est tombé en panne. Assurez-vous également que la création de fichiers volumineux (plus de 2 Go) est prise en charge lorsque votre machine utilise Network File System (NFS).

Alternative : traiter les fichiers principaux à l'aide d'ABRT dans RedHat Enterprise Linux 6 et versions ultérieures

La version 6.x de RedHat Linux et les versions ultérieures sont fournies avec un outil de signalement automatique des bogues (ABRT) qui collecte et stocke automatiquement les fichiers de vidage principaux dans /var/spool/abrt dossier . Si cela est préféré, des étapes supplémentaires sont nécessaires pour garantir que le core dump d’Intelligence Server puisse fonctionner avec ABRT. Pour une explication détaillée, veuillez consulter la explication officielle concernant l'ABRT.

Si vous avez suivi les étapes dans Activation du core dump, veuillez commenter ou supprimer les lignes suivantes de /etc/sysctl.conf.
Copier
```
kernel.core_pattern = /<path_to_the_location>/core/core.%e.%p.%h.%t
fs.suid_dumpable = 2
```
Activez la collecte de vidages de mémoire pour le serveur Intelligence, qui n'est ni signé ni packagé par RedHat. Pour ce faire, appliquez les lignes suivantes dans /etc/abrt/abrt-action-save-package-data.conf:
Copier
```
OpenGPGCheck = no
ProcessUnpackaged = yes
```
Configurez le dossier où le fichier principal sera enregistré, en ajoutant le paramètre suivant à /etc/abrt/abrt.conf. Par défaut, le paramètre est commenté et a la valeur /var/spool/abrt.
Copier
```
DumpLocation =/Your_desired/Path_to_generate/the_core_file
```
Redémarrez le service ABRT pour appliquer les paramètres mentionnés ci-dessus. Assurez-vous d’exécuter ces commandes en tant que root.
Copier
```
# service abrtd restart
# service abrt-ccpp start
```
Déclenchez le core dumping et vérifiez que le fichier core peut être créé en exécutant la commande ci-dessous. Il est essentiel d'exécuter ceci à partir de /IntelligenceServer dossier et notez l'emplacement du fichier principal créé.
Copier
```
# gcore -o <file> <pid>
```

Plusieurs remarques importantes :

Assurez-vous que DumpLocation existe et est accessible en écriture par le processus ABRT.
Si vous personnalisez DumpLocation, assurez-vous qu'il est différent du dossier spécifié pour WatchCrashdumpArchiveDir, qui est un autre paramètre dans abrt.conf fichier.
Si le fichier principal est tronqué ou qu'il n'est toujours pas vidé, vous pouvez consulter les journaux des messages système dans /var/log/messages pour rechercher la raison de l'échec du vidage principal.