[GH-ISSUE #1298] [Docs] Healthcheck #453

Closed
opened 2026-02-27 08:17:22 +03:00 by kerem · 2 comments
Owner

Originally created by @accforgithubtest on GitHub (Sep 17, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1298

May I pls request for clarification about the correct healthcheck for lldap (in a docker compose based setup).
Would be great if this is added to docs as well so the correct approach is documented.

Can you pls suggest If should stick to the health check from #451 ? Or Is the LLM's suggestion actually better ?

Going thru the older issues I see this example -

    healthcheck:
      test: /app/lldap healthcheck || exit 1
      interval: 60s
      retries: 5
      start_period: 20s
      timeout: 10s

But asking an LLM suggests this -

...

    healthcheck:
      test: ["CMD", "/app/lldap", "healthcheck", "--config-file", "/data/lldap_config.toml"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

... 


>>  why does the healthcheck need config file ? 

The lldap healthcheck needs the configuration file (--config-file) to perform a full and accurate verification of the running service. It goes beyond a basic check of whether the process is alive.

Here's why it's so important:

    Checks for Configuration Errors: The health check command reads the specified lldap_config.toml file. If there's a syntax error, a missing required parameter, or an invalid value, the health check will fail. This tells you immediately that the container is unhealthy due to a configuration issue, even if the process itself is technically running.

    Verifies External Dependencies: A well-designed health check should test connections to any external services a container depends on. By using the config file, the LLDAP health check can attempt to connect to its database (like PostgreSQL or SQLite) and verify that it has a working connection. This is a much more thorough check than just pinging a port.

    Ensures the Service is Ready: The health check confirms that LLDAP has loaded all its settings and is ready to serve requests. Without the config file, the health check would only confirm that the LLDAP binary can be executed, which doesn't guarantee the service is operational.

In short, pointing the health check to the config file ensures you're testing the live, configured state of the application, not just the existence of the process. It's the difference between checking if a car's engine is on and checking if it's on and has gas, a functioning transmission, and is in gear.
Originally created by @accforgithubtest on GitHub (Sep 17, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1298 May I pls request for clarification about the correct healthcheck for lldap (in a docker compose based setup). Would be great if this is added to docs as well so the correct approach is documented. Can you pls suggest If should stick to the health check from #451 ? Or Is the LLM's suggestion actually better ? Going thru the older issues I [see this example](https://github.com/lldap/lldap/issues/451#issuecomment-1430705142) - ```yaml healthcheck: test: /app/lldap healthcheck || exit 1 interval: 60s retries: 5 start_period: 20s timeout: 10s ``` But asking an LLM suggests this - ```yaml ... healthcheck: test: ["CMD", "/app/lldap", "healthcheck", "--config-file", "/data/lldap_config.toml"] interval: 30s timeout: 10s retries: 3 start_period: 30s ... ``` ``` >> why does the healthcheck need config file ? The lldap healthcheck needs the configuration file (--config-file) to perform a full and accurate verification of the running service. It goes beyond a basic check of whether the process is alive. Here's why it's so important: Checks for Configuration Errors: The health check command reads the specified lldap_config.toml file. If there's a syntax error, a missing required parameter, or an invalid value, the health check will fail. This tells you immediately that the container is unhealthy due to a configuration issue, even if the process itself is technically running. Verifies External Dependencies: A well-designed health check should test connections to any external services a container depends on. By using the config file, the LLDAP health check can attempt to connect to its database (like PostgreSQL or SQLite) and verify that it has a working connection. This is a much more thorough check than just pinging a port. Ensures the Service is Ready: The health check confirms that LLDAP has loaded all its settings and is ready to serve requests. Without the config file, the health check would only confirm that the LLDAP binary can be executed, which doesn't guarantee the service is operational. In short, pointing the health check to the config file ensures you're testing the live, configured state of the application, not just the existence of the process. It's the difference between checking if a car's engine is on and checking if it's on and has gas, a functioning transmission, and is in gear. ```
kerem closed this issue 2026-02-27 08:17:23 +03:00
Author
Owner

@martadinata666 commented on GitHub (Sep 17, 2025):

Both are right, in docker environment (mostly) don't need to read config because the lldap host will always exist, but when the config has a custom port, or URL, then lldap needs to read config first.

<!-- gh-comment-id:3301652300 --> @martadinata666 commented on GitHub (Sep 17, 2025): Both are right, in docker environment (mostly) don't need to read config because the lldap host will always exist, but when the config has a custom port, or URL, then lldap needs to read config first.
Author
Owner

@nitnelave commented on GitHub (Sep 17, 2025):

Basically, if you have to pass a specific CLI flag to start LLDAP by pointing it to the config file, you need the same for the health check. If you get it by default or through environment variables, you don't need anything for the health check (it also gets it)

<!-- gh-comment-id:3301957963 --> @nitnelave commented on GitHub (Sep 17, 2025): Basically, if you have to pass a specific CLI flag to start LLDAP by pointing it to the config file, you need the same for the health check. If you get it by default or through environment variables, you don't need anything for the health check (it also gets it)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#453
No description provided.