Commit 848b5144 authored by Stephane Bouvry's avatar Stephane Bouvry
Browse files

DOC : Erreur de boot Elasticsearch

parent 26e775eb
Loading
Loading
Loading
Loading
Loading
+110 −0
Changes for doc/errors/elasticsearch/service-no-boot.md: 110 added lines, 0 removed lines.
Original line number Diff line number Diff line
# ERREURS ELASTICSEARCH


## Start > exited with error code

**Symptome** : Le serveur ne démarre pas/plus avec le message : 

```
Job for elasticsearch.service failed because the control process exited with error code.
```

```bash
# Chercher des infos sur l'erreur
systemctl status elasticsearch.service --no-pager -l
```

On regarde les informations


### Main process exited, code=exited, status=78/CONFIG

Exemple de sortie : 
``` 
oct. 05 15:31:12 woscar-pp systemd[1]: Starting elasticsearch.service - Elasticsearch...
oct. 05 15:31:19 woscar-pp systemd-entrypoint[602]: WARNING: Unknown module: org.apache.arrow.memory.core specified to --add-opens
oct. 05 15:31:49 woscar-pp systemd-entrypoint[602]: WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
oct. 05 15:31:49 woscar-pp systemd-entrypoint[602]: WARNING: sun.misc.Unsafe::arrayBaseOffset has been called by com.google.protobuf.UnsafeUtil$MemoryAccessor (file:/usr/share/elasticsearch/
modules/x-pack-otel-data/protobuf-java-4.32.0.jar)
oct. 05 15:31:49 woscar-pp systemd-entrypoint[602]: WARNING: Please consider reporting this to the maintainers of class com.google.protobuf.UnsafeUtil$MemoryAccessor
oct. 05 15:31:49 woscar-pp systemd-entrypoint[602]: WARNING: sun.misc.Unsafe::arrayBaseOffset will be removed in a future release
oct. 05 15:31:57 woscar-pp systemd-entrypoint[602]: ERROR: Elasticsearch did not exit normally - check the logs at /var/log/elasticsearch/oscar-elastic.log
oct. 05 15:31:59 woscar-pp systemd-entrypoint[602]: Elasticsearch died while starting up, exit code: 78
oct. 05 15:31:59 woscar-pp systemd[1]: elasticsearch.service: Main process exited, code=exited, status=78/CONFIG
oct. 05 15:31:59 woscar-pp systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
oct. 05 15:31:59 woscar-pp systemd[1]: Failed to start elasticsearch.service - Elasticsearch.
oct. 05 15:31:59 woscar-pp systemd[1]: elasticsearch.service: Consumed 39.297s CPU time.
```

Note : Le code **status=78/CONFIG** indique une erreur de configuration et nous invite à allé voir les logs.

```bash
tail -100 /var/log/elasticsearch/oscar-elastic.log
```

```
[2026-10-06T15:34:59,528][INFO ][o.e.t.TransportService   ] [oscar-node-1] publish_address {10.14.128.162:9300}, bound_addresses {[::]:9300}
[2026-10-06T15:35:00,610][INFO ][o.e.b.BootstrapChecks    ] [oscar-node-1] bound or publishing to a non-loopback address, enforcing bootstrap checks
[2026-10-06T15:35:00,614][ERROR][o.e.b.Elasticsearch      ] [oscar-node-1] node validation exception
[1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch. For more information see [https://www.elastic.co/docs/deploy-mana
ge/deploy/self-managed/bootstrap-checks?version=9.5]
bootstrap check failure [1] of [1]: memory locking requested for elasticsearch process but memory is not locked; for more information see [https://www.elastic.co/docs/deploy-manage/deploy/se
lf-managed/bootstrap-checks?version=9.5#bootstrap-checks-memory-lock]
```

On cherche la ligne `[ERROR]`, elle nous précise la cause de l'erreur : *memory locking requested for elasticsearch process but memory is not locked*

En gros, soucis de mémoire

On regarde si une limite est fixée par **systemd** : 

```
systemctl show elasticsearch.service | grep -i LimitMEMLOCK
```

Affiche un truc du style : 

```
LimitMEMLOCK=8388608
LimitMEMLOCKSoft=8388608
```

Soit **8Mo**, c'est peu car on peut voir dans le log Elastic (`tail -100 /var/log/elasticsearch/oscar-elastic.log) que Elascticsearch a un *heap* de 1g9 (Cette valeur vient de la configuration d'Elasticsearch) : 
```
[2026-10-06T15:34:46,036][INFO ][o.e.e.NodeEnvironment    ] [oscar-node-1] using [1] data paths, mounts [[/ (/dev/sda1)]], net usable_space [3.5gb], net total_space [23.6gb], types [ext4]
[2026-10-06T15:34:46,037][INFO ][o.e.e.NodeEnvironment    ] [oscar-node-1] heap size [1.9gb], compressed ordinary object pointers [true]
[2026-10-06T15:34:46,084][INFO ][o.e.n.Node               ] [oscar-node-1] node name [oscar-node-1], node ID [9Hpy-sFqTIairEKDR4BaCg], cluster name [oscar-elastic], roles [ingest, data_froze
n, ml, data_hot, transform, data_content, data_warm, master, remote_cluster_client, data, data_cold]
```

**CORRECTIF** 

On va surcharger la configuration de Elasticsearch dans systemd : 

```bash
systemctl edit elasticsearch.service
```

```ini
[Service]
LimitMEMLOCK=infinity
```

> Attention, bien modifier la configuration dans la "zone commentée" sinon elle ne sera pas prise en compte, je me suis fait avoir :P

> Si vous êtes sur un système strict qui n'autorise pas `LimitMEMLOCK=infinity`, renseignez un valeur supérieur à la taille du *heap* d'elastic, par exemple : 
> ```ini
> [Service]
> LimitMEMLOCK=2G
> ```

Puis on recharge : 
```bash
sudo systemctl daemon-reload
```

On vérifie que c'est bien pris en compte : 
```bash
systemctl show elasticsearch.service | grep -i LimitMEMLOCK
```