# SearchGuard is not initialized just after a node joins a cluster **URL:** \ **Category:** Search Guard\ **Created:** [April 4, 2019, 7:10am UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421 "2019-04-04T07:10:12Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Tomoyuki](https://avatars.discourse-cdn.com/v4/letter/t/d9b06d/32.png) [@Tomoyuki](https://forum.search-guard.com/u/Tomoyuki)\ **Post date:** [April 4, 2019, 7:10am UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/1 "2019-04-04T07:10:13Z")
## Issue Assume there’s an ES cluster with SearchGuard initialized, where searchguard index exists. During the time between when a node joins the cluster and when the node completes loading SearchGuard configurations, an ES node does not accept any indexing requests because the node is considered to be not initialized yet. An client app receives the following error. ```auto org.elasticsearch.transport.RemoteTransportException: [(host)][(address)][indices:data/write/bulk] Caused by: org.elasticsearch.ElasticsearchSecurityException: Cannot authenticate null ``` The client app uses sniffing. That error happens because BackendRegistry is not initialized. [https://github.com/floragunncom/search-guard/blob/es-6.6.2/src/main/java/com/floragunn/searchguard/transport/SearchGuardRequestHandler.java#L228](https://github.com/floragunncom/search-guard/blob/es-6.6.2/src/main/java/com/floragunn/searchguard/transport/SearchGuardRequestHandler.java#L228) The error is transient, so retrying requests might work, but we might want to avoid the error if possible. ## Questions - Can we make sure the node is initialized before the node joins the cluster (when `searchguard` index exists)? - Any idea how to avoid this transient error? ## Version Elasticsearch: 6.6.1 SearchGuard: 24.1 ---
**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\ **Post date:** [April 4, 2019, 6:57pm UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/2 "2019-04-04T18:57:48Z")
---
**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\ **Post date:** [April 4, 2019, 6:58pm UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/3 "2019-04-04T18:58:36Z")
@cstaley any ideas regarding this issue? ---
**Author:** ![cstaley](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/cstaley/32/463_2.png) [@cstaley](https://forum.search-guard.com/u/cstaley)\ **Post date:** [April 5, 2019, 1:29pm UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/4 "2019-04-05T13:29:18Z")
I guess the only thing (beside retrying requests) is to use a loadbalancer which checks the health status of a node with our health check endpoint documented here [Installation | Security for Elasticsearch | Search Guard](https://docs.search-guard.com/latest/search-guard-installation#search-guard-health-check) (Or if not a loadbalancer maybe the client application can call the health check api on a regular basis) ---
**Author:** ![Tomoyuki](https://avatars.discourse-cdn.com/v4/letter/t/d9b06d/32.png) [@Tomoyuki](https://forum.search-guard.com/u/Tomoyuki)\ **Post date:** [April 8, 2019, 10:06am UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/5 "2019-04-08T10:06:28Z")
I see. Good to know the health check endpoint. We might be able to implement a custom sniffer to send requests to initialized nodes. It can be nice for SearchGuard library to provide the sniffer. 🙂 If we retry requests, can we check whether the failures can be transient for this case? ---
**Author:** ![cstaley](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/cstaley/32/463_2.png) [@cstaley](https://forum.search-guard.com/u/cstaley)\ **Post date:** [April 9, 2019, 10:36am UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/6 "2019-04-09T10:36:28Z")
What do you exactly mean with “can we check whether the failures can be transient for this case”? ---
**Author:** ![Tomoyuki](https://avatars.discourse-cdn.com/v4/letter/t/d9b06d/32.png) [@Tomoyuki](https://forum.search-guard.com/u/Tomoyuki)\ **Post date:** [April 10, 2019, 1:52am UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/7 "2019-04-10T01:52:43Z")
> What do you exactly mean with “can we check whether the failures can be transient for this case”? I thought it can be nice if a client can determine whether a failure can be resolved by retrying requests. For example, an `Exception` class might have a flag or code that indicates whether retrying might help or not. If a failure happens because SG is not initialized, clients might choose to retry requests until it’s initialized. If a failure happens due to insufficient privilege, clients might choose to stop sending requests. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/system/32/1870_2.png) [@system](https://forum.search-guard.com/u/system)\ **Post date:** [May 1, 2019, 1:52am UTC](https://forum.search-guard.com/t/searchguard-is-not-initialized-just-after-a-node-joins-a-cluster/1421/8 "2019-05-01T01:52:45Z")
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.