Sv translation

language	fr

Remarque
Cette page n'est plus actualisée. À partir de BlueMind 4.8, veuillez consulter la nouvelle documentation BlueMind

Volet

Sommaire

maxLevel	1

La barre de recherche ne propose pas l'option pour rechercher dans tous les dossiers

Pour l'ensemble des utilisateurs

Si c'est le cas pour l'ensemble des utilisateurs, cela fait probablement suite à une migration des mails au niveau du système de fichier. Cela signifie que l'index de recherche d'Elasticsearch n'existe pas : vous pouvez exécuter la tâche ConsolidateMailSpoolIndexJob pour créer l'index et indexer l'ensemble des mails du serveur :

se rendre dans la console d'administration > Gestion du système > Planification > exécuter la tâche ConsolidateMailSpoolIndexJob

ou

grâce à l'outil en ligne de commande exécuter l'opération de maintenance consolidateIndex :
Bloc de code
bm-cli maintenance consolidateIndex domain.net
Cette opération étant lourde en consommation de ressource, il est possible de l'exécuter par groupes d'utilisateurs grâce à l'option --match :
Bloc de code
bm-cli maintenance consolidateIndex --match "a.*" domain.net bm-cli maintenance consolidateIndex --match "[b-c].*" domain.net

Pour quelques utilisateurs

Si le problème ne concerne qu'un ou quelques utilisateurs, cela signifie que l'index ElasticSearch les concernant est inexistant ou corrompu, il faut le recréer :

soit en se rendant sur la fiche d'administration de chaque utilisateur, onglet Maintenance et en cliquant sur "Valider et réparer" puis "Consolider l'index"

soit grâce à l'outil en ligne de commande :

Bloc de code
bm-cli maintenance repair user@domain.net bm-cli maintenance consolidateIndex user@domain.net

Il manque des résultats dans la recherche

En cas de problèmes temporaires avec le service d'indexation il est possible que certains messages envoyés et reçus pendant cette période n'aient pas été indexés, dans ce cas il suffit d’exécuter la tâche ConsolidateMailSpoolIndexJob qui va calculer la différence entre les messages au niveau IMAP et dans l'index puis indexer uniquement les messages manquants.

Une erreur s'affiche lors d'une recherche

Cela peut provenir d'une incohérence entre la liste des dossiers au niveau IMAP et dans la base de données, l'action de maintenance "Valider et réparer" (opération check&repair) accessible depuis l'onglet Maintenance de la fiche utilisateur permet de reconstruire cette liste, une ré-indexation de la boite de messagerie doit ensuite corriger le problème (sur le même onglet "Reconstruire l'index de la boîte").

Si ce n'est pas le cas, les logs /var/log/bm-webmail/errors peuvent indiquer l'origine du problème.

Une erreur s'affiche lors de l'accès à un message trouvé par une recherche

Il s'agit probablement d'un défaut d'indexation lorsque qu'un message a été déplacé, l'action de maintenance "Consolider la boite mail" accessible depuis l'onglet Maintenance de la fiche utilisateur permet de mettre à jour l'index de recherche.

ElasticSearch passe en mode "read only"

Problème : ES se met lui-même en mode "read only", le cluster est vert mais un redémarrage ne corrige pas le problème

Symptômes constatés : globalement BlueMind semble ne plus fonctionner, outre les problème de recherche et affichage il est impossible de créer des événements, répondre à des mails, etc.

Confirmation : Dans les logs ElasticSearch, on trouve une trace semblable à celle-ci :

Bloc de code

2018-12-27 08:15:58,273 [BM-Core21] n.b.c.r.b.RestServiceMethodHandler ERROR - Error during restcall RestRequest [path=/internal-api/db_message_bodies/bm-master__blue-mind_loc/8b904e61a5d73ceb8b7e02048986a1740c94b3bb, method=PUT, User-Agent=null, params=, remoteAddresses=[192.168.132.14], origin=null]:  class net.bluemind.core.api.fault.ServerFault: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at net.bluemind.backend.mail.replica.service.internal.DbMessageBodiesService.create(DbMessageBodiesService.java:101)
    ... 18 common frames omitted
Caused by:
  class java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
    at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
    at net.bluemind.backend.mail.replica.service.internal.DbMessageBodiesService.create(DbMessageBodiesService.java:98)
    ... 18 common frames omitted

2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.s.ReplicationState ERROR - addMessage.create: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
net.bluemind.core.api.fault.ServerFault: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at net.bluemind.core.rest.base.codec.JsonObjectCodec.parseFault(JsonObjectCodec.java:111)
    at net.bluemind.core.rest.base.codec.DefaultResponseCodecs$VoidCodec.decode(DefaultResponseCodecs.java:288)
    at net.bluemind.core.rest.base.codec.DefaultResponseCodecs$VoidCodec.decode(DefaultResponseCodecs.java:1)
    at net.bluemind.core.rest.base.ClientProxyGenerator$MethodCallBuilder.parseResponse(ClientProxyGenerator.java:417)
    at net.bluemind.core.rest.base.ClientProxyGenerator$EventMethodInvoker$1.success(ClientProxyGenerator.java:215)
    at net.bluemind.core.rest.base.ClientProxyGenerator$EventMethodInvoker$1.success(ClientProxyGenerator.java:1)
    at net.bluemind.core.rest.log.CallLogger$1.success(CallLogger.java:48)
    at net.bluemind.core.rest.log.CallLogger$1.success(CallLogger.java:1)
    at net.bluemind.core.rest.base.RestRootHandler$1.success(RestRootHandler.java:130)
    at net.bluemind.core.rest.base.RestRootHandler$1.success(RestRootHandler.java:1)
    at net.bluemind.core.rest.base.RestRootHandler$VertxAwareAsyncHandler$1.handle(RestRootHandler.java:172)
    at net.bluemind.core.rest.base.RestRootHandler$VertxAwareAsyncHandler$1.handle(RestRootHandler.java:1)
    at org.vertx.java.core.impl.DefaultContext$2.run(DefaultContext.java:144)
    at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:464)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.lang.Thread.run(Thread.java:748)
2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.c.ApplyMessage INFO - Finished ApplyMessage.
2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.ReplicationSession INFO - REPL S: [frame-00001297]: OK success

Cause : l'espace disque sur le serveur est trop juste

Solution :

ajouter de l'espace disque (agrandir la partition, changer le disque, etc.)

une fois fait, jouer la commande suivante :

Bloc de code
curl -X PUT "localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d'{ "index.blocks.read_only_allow_delete" : false } }'

Les logs indiquent des erreurs à propos des quotas esQuota et imapQuota

On trouve des messages comme celui-ci dans le le fichier /var/log/bm-webmail/errors :

Bloc de code
10-Nov-2019 17:37:38 UTC] [jdoe@bluemind.loc] esQuota < (imapQuota * 0.8). disable es search. esQuota: 4199171, imapQuota: 6123568

Cela signifie que pour le compte indiqué, moins de 80% de la boite est indexé (esQuota = quota elasticsearch), la recherche elasticsearch (== le moteur de recherche avancé) est donc désactivée car inefficace.

Pour réparer cela, il faut procéder à une consolidation ou réindexation du compte.

Pour quelques utilisateurs identifiés

Si le problème ne concerne qu'un ou quelques utilisateurs, cela signifie que l'index ElasticSearch les concernant est inexistant ou corrompu, il faut le recréer :

soit en se rendant sur la fiche d'administration de chaque utilisateur et en cliquant sur "Valider et réparer" puis "Consolider l'index" puis, si pas d'amélioration, "Reconstruire l'index"

soit grâce à l'outil en ligne de commande :

Bloc de code
bm-cli maintenance repair user@domain.net bm-cli maintenance consolidateIndex user@domain.net

Pour l'ensemble des utilisateurs impactés

Pour réparer l'ensemble des comptes impactés, vous pouvez faire comme suit :

retrouver les comptes par un grep sur le fichier de log :
Bloc de code
grep "disable es search. esQuota:" /var/log/bm-webmail/errors
copier les logins ainsi trouvés dans un fichier texte (par exemple /tmp/accountWithoutEsSearch.txt)
utiliser la combinaison de commandes suivantes pour lancer la consolidation d'index sur chacun des logins du fichier :
Bloc de code
while read account; do bm-cli maintenance consolidatedIndex $account;done < /tmp/accountWithoutEsSearch.txt

Dysfonctionnement global

Analyse

Si vous constatez un dysfonctionnement de la recherche dans BlueMind vous pouvez consulter l'état du cluster ElasticSearch avec la commande :

Bloc de code
$ curl -XGET --silent 'http://localhost:9200/_cluster/health'

Si le statut est 'green' tout va bien, s'il est 'red' cela signifie qu'il y a un problème au niveau d'Elasticsearch. Cette information remonte également dans la console de monitoring.

Grâce à l'outil d'administration en ligne de commande, vous pouvez consulter l'état de l'index d'un utilisateur donné :

Bloc de code
$ bm-cli index info admin@local.lan {"email":"jdoe@domain.loc","ESQuota":3056,"IMAPQuota":3058,"ratio":95}

Résolution

Plusieurs conditions peuvent empêcher le fonctionnement d'ElasticSearch :

une boîte insuffisamment indexée : si en consultant l'index (voir ci-dessus) on constate un ratio inférieur à 80, cela signifie que moins de 80% des emails de l'utilisateur sont indexés procéder à une réindexation de la boîte :
- se rendre dans la console d'administration de BlueMind
- aller dans la fiche d'administration de l'utilisateur > onglet Maintenance
- exécuter l'opération "Reconstruire l'index de la boîte aux lettres"

une corruption des index : principalement à cause d'un manque d'espace disque, il faut au minimum 10% d'espace disque libre. Si le disque contenant les données d'ES (/var/spool/bm-elasticsearch) a manqué d'espace il est possible que les index de recherche soient corrompus. Dans les logs ES, cela se traduit par une erreur lors du démarrage du service :

Bloc de code

[2017-01-26 20:06:54,764][WARN ][cluster.action.shard] [Bill Foster] [mailspool][0] received shard failed for [mailspool][0], node[PcC6eICxRAajmWioK1mhDA], [P], s[INITIALIZING], indexUUID 
[IEJHQkOnTtOcdY0bMMIFRA], reason [master [Bill Foster][PcC6eICxRAajmWioK1mhDA][bluemind.exa.net.uk][inet[/82.219.13.101:9300]] marked shard as initializing, but shard is marked as failed, resend shard failure]
[2016-01-26 20:06:55,828][WARN ][indices.cluster] [Bill Foster] [mailspool][0] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [mailspool][0] failed to recover shard
        at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
        at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

Il faut alors :

supprimer les fichiers d'index et redémarrer ElasticSearch :

Bloc de code

language	bash

service bm-elasticsearch stop
rm -rf /var/spool/bm-elasticsearch/data/nodes/0/indices/*
service bm-elasticsearch start

Réinitialiser les index :

Bloc de code
bm-cli index reset mailspool bm-cli index reset mailspool_pending bm-cli index reset event bm-cli index reset contact bm-cli index reset todo bm-cli index reset im

Puis lancer une nouvelle indexation depuis la gestion des tâches planifiées : Console d'administration > Gestion du système > Planification > sélectionner le domaine "global.virt" et lancer les tâches *IndexJob :

CalendarIndexJob
ContactIndexJob

ConsolidateMailSpoolIndexJob

Avertissement
Attention cependant, l'indexation des mails est une opération consommatrice en IO, il est donc préférable de lancer cette tâche en soirée ou en week-end. A noter qu'il est possible de lancer l'indexation par lot avec bm-cli.

TodoListIndexJob
HSMIndexJob

une corruption du translog : cela peut se produire en cas de crash du serveur ou de manque de mémoire. Dans ce cas l'index général n'est pas corrompu et seule l'indexation des derniers documents non encore écrits sur le disque sera perdue.
Dans les logs ES, cela se traduit par cette erreur lors du démarrage du service :

Bloc de code

[2017-09-04 19:24:38,340][WARN ][indices.cluster          ] [Hebe] [mailspool][1] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [mailspool][1] failed to recover shard
	at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
	at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.index.translog.TranslogCorruptedException: translog corruption while reading from stream
	at org.elasticsearch.index.translog.ChecksummedTranslogStream.read(ChecksummedTranslogStream.java:70)
	at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:257)
	... 4 more

Pour supprimer les translog corrompu :

Bloc de code
service bm-elasticsearch stop rm -rf /var/spool/bm-elasticsearch/data/nodes/0/indices/mailspool/*/translog service bm-elasticsearch start

L’exécution de la tâche ConsolidateMailSpoolIndexJob va ré-indexer les mails manquants

Sv translation

language	en

Remarque
This page is no longer being updated. From BlueMind 4.8, please refer to the new BlueMind documentation

Volet

Sommaire

maxLevel	1

The search bar doesn't show the option to search all folders

For all users

If all users are affected, the issue probably occurs following an email migration at the folder system level. This means that the Elasticsearch search index doesn't exist: you can run ConsolidateMailSpoolIndexJob to create the index and index all the messages on the server:

go to the admin console > System Management > Planning > run ConsolidateMailSpoolIndexJob

or

using our command line tool, run the consolidateIndex maintenance operation:
Bloc de code
bm-cli maintenance consolidateIndex domain.net
This operation is resource hungry. From BlueMind 3.5.12, you can run it by groups of users using the option --match:
Bloc de code
bm-cli maintenance consolidateIndex --match "a.*" domain.net bm-cli maintenance consolidateIndex --match "[b-c].*" domain.net

For a few users only

If the issue affects a few users only, this means that their ElasticSearch index doesn't exist or is corrupt, you therefore have to create it:

either by going into each user's admin page and running "Validate and repair user data" next "Consolidate mailbox index".

or using our command line tool:

Bloc de code
bm-cli maintenance repair user@domain.net bm-cli maintenance consolidateIndex user@domain.net

Some search results are missing

In case of temporary issues with the indexing service, some messages sent or received during that period may not have been indexed. Simply run ConsolidateMailSpoolIndexJob which computes the difference between messages within IMAP and the index, and then indexes the missing messages only.

Error message during searches

This may be caused by an inconsistency between the list of IMAP folders and the database. You can use the "validate and repair" (check and repair) maintenance operation -- which can be accessed from the Maintenance tab in the user's admin page – to rebuild this list. Then re-indexing the mailbox should fix the issue.

If this isn't the case, /var/log/bm-webmail.errors logs may the cause.

An error message appears when trying to access a message found by search

This is probably due to an indexing fault when the message was moved. You can use the "Consolidate mailbox index" maintenance operation – which can be accessed from the Maintenance tab in the user's admin page – to update the search index.

ElasticSearch goes into "read-only" mode

Issue: ES puts itself in "read-only" mode, the cluster is green but a restart doesn't fix the issue.

Symptoms: Overall, BlueMind doesn't seem to work any more. Besides search and display issues, users can't create events, reply to emails, etc.

Confirmation: In ElasticSearch logs, you will find traces such as:

Bloc de code

2018-12-27 08:15:58,273 [BM-Core21] n.b.c.r.b.RestServiceMethodHandler ERROR - Error during restcall RestRequest [path=/internal-api/db_message_bodies/bm-master__blue-mind_loc/8b904e61a5d73ceb8b7e02048986a1740c94b3bb, method=PUT, User-Agent=null, params=, remoteAddresses=[192.168.132.14], origin=null]:  class net.bluemind.core.api.fault.ServerFault: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at net.bluemind.backend.mail.replica.service.internal.DbMessageBodiesService.create(DbMessageBodiesService.java:101)
    ... 18 common frames omitted
Caused by:
  class java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
    at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
    at net.bluemind.backend.mail.replica.service.internal.DbMessageBodiesService.create(DbMessageBodiesService.java:98)
    ... 18 common frames omitted

2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.s.ReplicationState ERROR - addMessage.create: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
net.bluemind.core.api.fault.ServerFault: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at net.bluemind.core.rest.base.codec.JsonObjectCodec.parseFault(JsonObjectCodec.java:111)
    at net.bluemind.core.rest.base.codec.DefaultResponseCodecs$VoidCodec.decode(DefaultResponseCodecs.java:288)
    at net.bluemind.core.rest.base.codec.DefaultResponseCodecs$VoidCodec.decode(DefaultResponseCodecs.java:1)
    at net.bluemind.core.rest.base.ClientProxyGenerator$MethodCallBuilder.parseResponse(ClientProxyGenerator.java:417)
    at net.bluemind.core.rest.base.ClientProxyGenerator$EventMethodInvoker$1.success(ClientProxyGenerator.java:215)
    at net.bluemind.core.rest.base.ClientProxyGenerator$EventMethodInvoker$1.success(ClientProxyGenerator.java:1)
    at net.bluemind.core.rest.log.CallLogger$1.success(CallLogger.java:48)
    at net.bluemind.core.rest.log.CallLogger$1.success(CallLogger.java:1)
    at net.bluemind.core.rest.base.RestRootHandler$1.success(RestRootHandler.java:130)
    at net.bluemind.core.rest.base.RestRootHandler$1.success(RestRootHandler.java:1)
    at net.bluemind.core.rest.base.RestRootHandler$VertxAwareAsyncHandler$1.handle(RestRootHandler.java:172)
    at net.bluemind.core.rest.base.RestRootHandler$VertxAwareAsyncHandler$1.handle(RestRootHandler.java:1)
    at org.vertx.java.core.impl.DefaultContext$2.run(DefaultContext.java:144)
    at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:464)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.lang.Thread.run(Thread.java:748)
2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.c.ApplyMessage INFO - Finished ApplyMessage.
2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.ReplicationSession INFO - REPL S: [frame-00001297]: OK success

Cause: The server disk space is too tight

Solution:

add disk space (increase the partition, change the disk, etc.)

once this is done, play the following command:

Bloc de code
curl -X PUT "localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d'{ "index.blocks.read_only_allow_delete" : false } }'

Logs show esQuota and imapQuota errors

You find messages such as the one below in /var/log/bm-webmail/errors:

Bloc de code
10-Nov-2019 17:37:38 UTC] [jdoe@bluemind.loc] esQuota < (imapQuota * 0.8). disable es search. esQuota: 4199171, imapQuota: 6123568

This means that for the account shown, less than 80% of the mailbox is indexed (esQuota = elasticsearch quota), elasticsearch search (== advanced search engine) is therefore disabled because inefficient.

To fix this, you have to consolidate or reindex the account.

If only a few identified users are affected

If the issue only affects one or a few users, this means that their ElasticSearch index doesn't exist or is corrupt – it has to be created again:

either by going into each user's admin page and executing "Validate and repair user data" then "Consolidate mailbox index" then, if there's no improvement, "Reconstruct mailbox index"

or by using our command line tool:

Bloc de code
bm-cli maintenance repair user@domain.net bm-cli maintenance consolidateIndex user@domain.net

If all users are affected

To repair all accounts, you can:

find the accounts by running a grep on the log file:
Bloc de code
grep "disable es search. esQuota:" /var/log/bm-webmail/errors
copy the logins found into a text file (e.g. /tmp/accountWithoutEsSearch.txt)
use the following command combination to start the consolidation of the index for each file login:
Bloc de code
while read account; do bm-cli maintenance consolidatedIndex $account;done < /tmp/accountWithoutEsSearch.txt

Global malfunction

Analyse

If you detect a search malfunction in BlueMind, you can see the status of the ElasticSearch cluster using the command:

Bloc de code
curl -XGET --silent 'http://localhost:9200/_cluster/health'

If the cluster's status is 'green' then everything is fine, if it is 'red', this means there is an issue with Elasticsearch. This information is also fed into the monitoring console.

Using our command line admin tool, you can check a user's indexing status:

Bloc de code
$ bm-cli index info admin@local.lan {"email":"jdoe@domain.loc","ESQuota":3056,"IMAPQuota":3058,"ratio":95}

Solution

Several issues may stop ElasticSearch from working:

an insufficiently indexed mailbox: if, when you check the index (see above), you find a ratio below 80, this means that fewer than 80% of the user's emails are indexed Image Modified you must reindex the mailbox:
- go to the BlueMind admin console
- go to the user's admin page > Maintenance tab
- run "Reconstruct mailbox index"

corrupt index: mainly due to low disk space. You need at least 10% of free disk space. If the disk containing ES data (/var/spool/bm-elasticsearch) has been short on space, search indices may have become corrupt. In ES logs, this translates as an error on service start up:

Bloc de code

[2017-01-26 20:06:54,764][WARN ][cluster.action.shard] [Bill Foster] [mailspool][0] received shard failed for [mailspool][0], node[PcC6eICxRAajmWioK1mhDA], [P], s[INITIALIZING], indexUUID 
[IEJHQkOnTtOcdY0bMMIFRA], reason [master [Bill Foster][PcC6eICxRAajmWioK1mhDA][bluemind.exa.net.uk][inet[/82.219.13.101:9300]] marked shard as initializing, but shard is marked as failed, resend shard failure]
[2016-01-26 20:06:55,828][WARN ][indices.cluster] [Bill Foster] [mailspool][0] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [mailspool][0] failed to recover shard
        at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
        at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

You must therefore:

Remove the index files and restart ElasticSearch:

Bloc de code

language	bash

service bm-elasticsearch stop
rm -rf /var/spool/bm-elasticsearch/data/nodes/0/indices/*
service bm-elasticsearch start

Reset the indices:

Bloc de code
bm-cli index reset mailspool bm-cli index reset mailspool_pending bm-cli index reset event bm-cli index reset contact bm-cli index reset todo bm-cli index reset im

Then start indexing again from scheduled jobs: Admin Console > System Management > Planning > select the domain "global.virt" and run all the *IndexJob jobs:
- CalendarIndexJob
- ContactIndexJob
- ConsolidateMailSpoolIndexJob
  Avertissement
  Email indexing is IO hungry, so we recommend that you run it in the evening or at the weekend. You can also run the indexing by lot using bm-cli.
- TodoListIndexJob
- HSMIndexJob

corrupt translog: this can happen if the server has crashed or because of low memory. In this case, the general index is not corrupt and only the indexing of documents not written to the disk yet will be lost.
In ES logs, this translates as the following error during service restart:

Bloc de code

[2017-09-04 19:24:38,340][WARN ][indices.cluster          ] [Hebe] [mailspool][1] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [mailspool][1] failed to recover shard
	at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
	at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.index.translog.TranslogCorruptedException: translog corruption while reading from stream
	at org.elasticsearch.index.translog.ChecksummedTranslogStream.read(ChecksummedTranslogStream.java:70)
	at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:257)
	... 4 more

To remove the corrupt translogs:

Bloc de code
service bm-elasticsearch stop rm -rf /var/spool/bm-elasticsearch/data/nodes/0/indices/mailspool/*/translog service bm-elasticsearch start

Running ConsolidateMailSpoolIndexJob reindexes the missing messages.

Sv translation

language	de

Remarque
Diese Seite ist nicht mehr aktuell. Ab der Version BlueMind 4.8 finden Sie alle Infos in der neuen Dokumentation

Volet

Sommaire

maxLevel	1

Die Suchleiste bietet nicht die Möglichkeit, in allen Ordnern zu suchen

Für alle Benutzer

Wenn dies bei allen Benutzern der Fall ist, liegt es wahrscheinlich an einer Mail-Migration auf Dateisystemebene. Das bedeutet, dass der Suchindex von Elasticsearch nicht existiert: Sie können die Aufgabe ConsolidateMailSpoolIndexJob ausführen, um den Index zu erstellen und alle Mails des Servers zu indizieren:

gehen Sie zur Administrationskonsole > Systemadministration > Planung > führen Sie die Aufgabe ConsolidateMailSpoolIndexJob aus

oder

führen Sie mit dem Kommandozeilen-Tool die Wartungsoperation consolidateIndex durch:
Bloc de code
bm-cli maintenance consolidateIndex domain.net
Da diese Operation mit einem hohen Ressourcenverbrauch verbunden ist, ist es möglich, sie mit der Option --match für Gruppen von Benutzern auszuführen:
Bloc de code
bm-cli maintenance consolidateIndex --match "a.*" domain.net bm-cli maintenance consolidateIndex --match "[b-c].*" domain.net

Einige Benutzer

Wenn das Problem nur einen oder wenige Benutzer betrifft, bedeutet dies, dass der ElasticSearch-Index, der sie betrifft, nicht vorhanden oder beschädigt ist; er muss neu erstellt werden:

entweder, indem Sie im Verwaltungsformular jedes Benutzers auf die Registerkarte "Wartung" gehen und auf "Validieren und reparieren" und dann auf "Index konsolidieren" klicken

oder mit dem Kommandozeilen-Tool:

Bloc de code
bm-cli maintenance repair user@domain.net bm-cli maintenance consolidateIndex user@domain.net

Es fehlen Ergebnisse in der Suche

Bei temporären Problemen mit dem Indizierungsdienst ist es möglich, dass einige in diesem Zeitraum gesendete und empfangene Nachrichten nicht indiziert wurden. In diesem Fall führen Sie einfach die Task ConsolidateMailSpoolIndexJob aus, die die Differenz zwischen den Nachrichten auf IMAP-Ebene und im Index berechnet und nur die fehlenden Nachrichten indiziert.

Bei einer Suche wird ein Fehler angezeigt

Dies kann auf eine Inkonsistenz zwischen der Liste der Ordner auf IMAP-Ebene und in der Datenbank zurückzuführen sein, die Wartungsaktion "Validieren und reparieren" (Operation check&repair), die über die Registerkarte "Wartung" des Benutzerstammsatzes zugänglich ist, ermöglicht es, diese Liste neu aufzubauen. Eine Neuindizierung des Posteingangs muss das Problem beheben (auf derselben Registerkarte "Index des Posteingangs neu aufbauen").

Falls nicht, liegt der Ursprung des Problems möglicherweise in den Logdateien /var/log/bm-webmail/errors.

Beim Zugriff auf eine über eine Suche gefundene Nachricht wird ein Fehler angezeigt

Es handelt sich wahrscheinlich um einen bei Verschieben der Nachricht entstandenen Indizierungsfehler. Die Wartungsaktion "Posteingang konsolidieren", die über die Registerkarte "Wartung" des Benutzerstammsatzes zugänglich ist, ermöglicht die Aktualisierung des Suchindexes.

ElasticSearch (ES) wechselt in den "read only"-Modus

Problem: ES versetzt sich in den "read only"-Modus, der Cluster ist grün, aber ein Neustart behebt das Problem nicht

Festgestellte Symptome: BlueMind scheint insgesamt nicht mehr zu funktionieren, neben den Problemen bei Suche und Anzeige ist es nicht möglich, Termine zu erstellen, Mails zu beantworten, usw.

Bestätigung: In den ElasticSearch-Logdateien ein Trace dieses Typs zu finden:

Bloc de code

2018-12-27 08:15:58,273 [BM-Core21] n.b.c.r.b.RestServiceMethodHandler ERROR - Error during restcall RestRequest [path=/internal-api/db_message_bodies/bm-master__blue-mind_loc/8b904e61a5d73ceb8b7e02048986a1740c94b3bb, method=PUT, User-Agent=null, params=, remoteAddresses=[192.168.132.14], origin=null]:  class net.bluemind.core.api.fault.ServerFault: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at net.bluemind.backend.mail.replica.service.internal.DbMessageBodiesService.create(DbMessageBodiesService.java:101)
    ... 18 common frames omitted
Caused by:
  class java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
    at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
    at net.bluemind.backend.mail.replica.service.internal.DbMessageBodiesService.create(DbMessageBodiesService.java:98)
    ... 18 common frames omitted

2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.s.ReplicationState ERROR - addMessage.create: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
net.bluemind.core.api.fault.ServerFault: java.util.concurrent.ExecutionException: ClusterBlockException[blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]
    at net.bluemind.core.rest.base.codec.JsonObjectCodec.parseFault(JsonObjectCodec.java:111)
    at net.bluemind.core.rest.base.codec.DefaultResponseCodecs$VoidCodec.decode(DefaultResponseCodecs.java:288)
    at net.bluemind.core.rest.base.codec.DefaultResponseCodecs$VoidCodec.decode(DefaultResponseCodecs.java:1)
    at net.bluemind.core.rest.base.ClientProxyGenerator$MethodCallBuilder.parseResponse(ClientProxyGenerator.java:417)
    at net.bluemind.core.rest.base.ClientProxyGenerator$EventMethodInvoker$1.success(ClientProxyGenerator.java:215)
    at net.bluemind.core.rest.base.ClientProxyGenerator$EventMethodInvoker$1.success(ClientProxyGenerator.java:1)
    at net.bluemind.core.rest.log.CallLogger$1.success(CallLogger.java:48)
    at net.bluemind.core.rest.log.CallLogger$1.success(CallLogger.java:1)
    at net.bluemind.core.rest.base.RestRootHandler$1.success(RestRootHandler.java:130)
    at net.bluemind.core.rest.base.RestRootHandler$1.success(RestRootHandler.java:1)
    at net.bluemind.core.rest.base.RestRootHandler$VertxAwareAsyncHandler$1.handle(RestRootHandler.java:172)
    at net.bluemind.core.rest.base.RestRootHandler$VertxAwareAsyncHandler$1.handle(RestRootHandler.java:1)
    at org.vertx.java.core.impl.DefaultContext$2.run(DefaultContext.java:144)
    at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:464)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.lang.Thread.run(Thread.java:748)
2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.c.ApplyMessage INFO - Finished ApplyMessage.
2018-12-27 08:15:58,274 [vert.x-eventloop-thread-1] n.b.b.c.r.s.ReplicationSession INFO - REPL S: [frame-00001297]: OK success

Ursache: Der Speicherplatz auf dem Server ist zu klein

Lösung:

Speicherplatz hinzufügen (Partition vergrößern, Festplatte wechseln usw.)

Sobald dies geschehen ist, geben Sie den folgenden Befehl ein:

Bloc de code
curl -X PUT "localhost:9200/_all/_settings" -H 'Content-Type: application/json' -d'{ "index.blocks.read_only_allow_delete" : false } }'

Logdateien zeigen Fehler in Bezug auf esQuota- und imapQuota-Kontingente an

Meldungen wie diese sind in der Datei /var/log/bm-webmail/errors zu finden:

Bloc de code
10-Nov-2019 17:37:38 UTC] [jdoe@bluemind.loc] esQuota < (imapQuota * 0.8). disable es search. esQuota: 4199171, imapQuota: 6123568

Das bedeutet, dass für das angegebene Konto weniger als 80 % des Posteingangs indiziert sind (esQuota = quota elasticsearch), die elasticsearch-Suche (== die erweiterte Suchmaschine) ist daher deaktiviert, da sie ineffizient ist.

Um dies zu beheben, muss das Konto konsolidiert oder neu indiziert werden.

Für einige identifizierte Benutzer

Wenn das Problem nur einen oder wenige Benutzer betrifft, bedeutet dies, dass der ElasticSearch-Index, der sie betrifft, nicht vorhanden oder beschädigt ist; er muss neu erstellt werden:

Entweder, indem Sie in der Administrationsdatei jedes Benutzers auf "Validieren und reparieren", dann auf "Index konsolidieren" und dann, wenn keine Verbesserung eintritt, auf "Index neu aufbauen" klicken

oder mit dem Kommandozeilen-Tool:

Bloc de code
bm-cli maintenance repair user@domain.net bm-cli maintenance consolidateIndex user@domain.net

Für alle betroffenen Benutzer

Um alle betroffenen Konten zu reparieren, können Sie wie folgt vorgehen:

die Konten durch einen grep auf der Logdatei abrufen:
Bloc de code
grep "disable es search. esQuota:" /var/log/bm-webmail/errors
die gefundenen Logins in eine Textdatei kopieren (z.B. /tmp/accountWithoutEsSearch.txt)
verwenden Sie die folgende Befehlskombination, um die Indexkonsolidierung für jeden Login der Datei zu starten:
Bloc de code
while read account; do bm-cli maintenance consolidatedIndex $account;done < /tmp/accountWithoutEsSearch.txt

Globale Störung

Analyse

Wenn Sie eine Fehlfunktion der Suche in BlueMind bemerken, können Sie den Zustand des ElasticSearch-Clusters mit dem folgenden Befehl aufrufen:

Bloc de code
$ curl -XGET --silent 'http://localhost:9200/_cluster/health'

Wenn der Status 'green' ist, ist alles in Ordnung, wenn er 'red' ist, liegt ein Problem mit Elasticsearch vor. Diese Informationen werden auch in der Monitoringkonsole angezeigt.

Mit dem Kommandozeilen-Administrationswerkzeug können Sie den Indexstatus eines bestimmten Benutzers anzeigen:

Bloc de code
$ bm-cli index info admin@local.lan {"email":"jdoe@domain.loc","ESQuota":3056,"IMAPQuota":3058,"ratio":95}

Lösung

Mehrere Bedingungen können verhindern, dass ElasticSearch funktioniert:

Ein unzureichend indizierter Posteingang: Wenn der Index (siehe oben) ein Verhältnis von weniger als 80 anzeigt, bedeutet dies, dass weniger als 80 % der E-Mails des Benutzers indiziert sind Image Modified eine Neuindizierung des Posteingangs durchführen:
- zur BlueMind-Administrationskonsole gehen
- Verwaltungsdatei des Benutzers > Registerkarte Wartung
- den Vorgang "Posteingang-Index neu aufbauen" ausführen

Beschädigung des Index: Hauptsächlich aufgrund eines Mangels an Festplattenplatz, der freie Festplattenplatz muss mindestens 10 % betragen. Wenn auf dem Datenträger mit den ES-Daten (/var/spool/bm-elasticsearch) nicht genug Platz verfügbar war, ist es möglich, dass die Suchindizes beschädigt sind. In den ES-Logdateien führt dies zu einem Fehler beim Starten des Dienstes:

Bloc de code

[2017-01-26 20:06:54,764][WARN ][cluster.action.shard] [Bill Foster] [mailspool][0] received shard failed for [mailspool][0], node[PcC6eICxRAajmWioK1mhDA], [P], s[INITIALIZING], indexUUID 
[IEJHQkOnTtOcdY0bMMIFRA], reason [master [Bill Foster][PcC6eICxRAajmWioK1mhDA][bluemind.exa.net.uk][inet[/82.219.13.101:9300]] marked shard as initializing, but shard is marked as failed, resend shard failure]
[2016-01-26 20:06:55,828][WARN ][indices.cluster] [Bill Foster] [mailspool][0] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [mailspool][0] failed to recover shard
        at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
        at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

Gehen Sie in diesem Fall wie folgt vor:

Die Indexdateien löschen und ElasticSearch neu starten:

Bloc de code

language	bash

service bm-elasticsearch stop
rm -rf /var/spool/bm-elasticsearch/data/nodes/0/indices/*
service bm-elasticsearch start

Indizes zurücksetzen:

Bloc de code
bm-cli index reset mailspool bm-cli index reset mailspool_pending bm-cli index reset event bm-cli index reset contact bm-cli index reset todo bm-cli index reset im

Starten Sie dann eine neue Indizierung aus der Verwaltung der geplanten Aufgaben: Administrationskonsole > Systemadministration > Planung > wählen Sie die Domain "global.virt" und starten Sie die Aufgaben *IndexJob:

CalendarIndexJob
ContactIndexJob

ConsolidateMailSpoolIndexJob

Avertissement
Aber aufgepasst: das Indizieren von E-Mails ist ein Vorgang, der viel Zeit in Anspruch nimmt und es ist ratsam, diese Aufgabe abends oder am Wochenende zu starten. Es ist außerdem möglich, mit bm-cli die Batch-Indizierung zu starten.

TodoListIndexJob
HSMIndexJob

Beschädigung des translog : Dies kann bei einem Server-Absturz oder fehlendem Speicherplatz geschehen. In diesem Fall wird der allgemeine Index nicht beschädigt und nur die Indizierung der letzten noch nicht auf die Festplatte geschriebenen Dokumente geht verloren.
In ES-Protokollen führt dies zu diesem Fehler beim Starten des Dienstes:

Bloc de code

[2017-09-04 19:24:38,340][WARN ][indices.cluster          ] [Hebe] [mailspool][1] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [mailspool][1] failed to recover shard
	at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:287)
	at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.elasticsearch.index.translog.TranslogCorruptedException: translog corruption while reading from stream
	at org.elasticsearch.index.translog.ChecksummedTranslogStream.read(ChecksummedTranslogStream.java:70)
	at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:257)
	... 4 more

Entfernen eines beschädigten Translog:

Bloc de code
service bm-elasticsearch stop rm -rf /var/spool/bm-elasticsearch/data/nodes/0/indices/mailspool/*/translog service bm-elasticsearch start

Durch Ausführen der Aufgabe ConsolidateMailSpoolIndexJob werden die fehlenden Mails neu indiziert

Arborescence des pages

Historique de la page

Comparaison des versions

Ancienne version 43

Nouvelle version Actuel

Légende

La barre de recherche ne propose pas l'option pour rechercher dans tous les dossiers

Pour l'ensemble des utilisateurs

Pour quelques utilisateurs

Il manque des résultats dans la recherche

Une erreur s'affiche lors d'une recherche

Une erreur s'affiche lors de l'accès à un message trouvé par une recherche

ElasticSearch passe en mode "read only"

Les logs indiquent des erreurs à propos des quotas esQuota et imapQuota

Pour quelques utilisateurs identifiés

Pour l'ensemble des utilisateurs impactés

Dysfonctionnement global

Analyse

Résolution

The search bar doesn't show the option to search all folders

For all users

For a few users only

Some search results are missing

Error message during searches

An error message appears when trying to access a message found by search

ElasticSearch goes into "read-only" mode

Logs show esQuota and imapQuota errors

If only a few identified users are affected

If all users are affected

Global malfunction

Analyse

Solution

Die Suchleiste bietet nicht die Möglichkeit, in allen Ordnern zu suchen

Für alle Benutzer

Einige Benutzer

Es fehlen Ergebnisse in der Suche

Bei einer Suche wird ein Fehler angezeigt

Beim Zugriff auf eine über eine Suche gefundene Nachricht wird ein Fehler angezeigt

ElasticSearch (ES) wechselt in den "read only"-Modus

Logdateien zeigen Fehler in Bezug auf esQuota- und imapQuota-Kontingente an

Für einige identifizierte Benutzer

Für alle betroffenen Benutzer

Globale Störung

Analyse

Lösung