Repository navigation
Health endpoint returns UP every 10 requests #37785
Before reporting an issue
Areaadmin/api Describe the bugHi, I have noticed that something odd. {
"status": "UP",
"checks": [
{
"name": "Keycloak database connections async health check",
"status": "UP"
}
]
}I have noticed that so I wanted to verify if it was every 10 times or every couple of seconds. [root@almatest ~]# while true; do curl -k https://testkc:9000/management/health; echo; done
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
{
"status": "UP",
"checks": [
{
"name": "Keycloak database connections async health check",
"status": "UP"
}
]
}
[root@almatest ~]# while true; do curl -k https://testkc:9000/management/health; echo; sleep 3; done
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
<html><body><h1>Resource not found</h1></body></html>
{
"status": "UP",
"checks": [
{
"name": "Keycloak database connections async health check",
"status": "UP"
}
]
}Can you tell me if I am doing something wrong or what could be the issue? Keycloak version: bash-5.1$ cat /opt/keycloak/version.txt
Keycloak - Version 26.1.2My Container file: FROM quay.io/keycloak/keycloak:latest AS builder
# Build options
ENV KC_HEALTH_ENABLED=true
ENV KC_METRICS_ENABLED=true
ENV KC_DB=postgres
ENV KC_HTTP_RELATIVE_PATH=/kc
ENV KC_HTTP_MANAGEMENT_RELATIVE_PATH=/management
WORKDIR /opt/keycloak
RUN /opt/keycloak/bin/kc.sh build
FROM quay.io/keycloak/keycloak:latest
COPY --from=builder /opt/keycloak/ /opt/keycloak/
ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]Service file (how i ran container): # /etc/systemd/system/keycloak.service
[Unit]
Description=Keycloak server
After=network.target
[Service]
Type=forking
Restart=on-failure
RestartSec=30
TimeoutStartSec=300
PIDFile=/%t/%n-pid
KillMode=none
ExecStartPre=/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid -d --env-file /etc/systemd/system/keycloak.service.d/environment.conf --name keycloak \
-p 192.168.50.90:9000:9000 \
--log-opt max-size=10m \
-v /etc/ssl/certs/testkc.jks:/opt/keycloak/conf/testkc.jks:z \
-v /etc/nginx/ssl/testkc.key:/opt/keycloak/conf/testkc.key:z \
-v /etc/nginx/ssl/testkc.crt:/opt/keycloak/conf/testkc.crt:z \
-v /opt/podman-keycloak/keystore.p12:/opt/keycloak/conf/keystore.p12:z \
-v keycloak-storage:/opt/keycloak/data/log \
localhost/keycloak:latest start --optimized --config-keystore=/opt/keycloak/conf/keystore.p12 --config-keystore-password=keystorepass --config-keystore-type=PKCS12
ExecStop=/usr/bin/sh -c "/usr/bin/podman rm -f $(cat /%t/%n-cid)"
# /etc/systemd/system/keycloak.service.d/environment.conf
[Service]
KC_DB=postgres
KC_DB_URL=jdbc:postgresql://192.168.50.171:5432/keycloakdb
KC_DB_USERNAME=keycloakadmin
KC_HOSTNAME=https://testkc:9000/kc
KC_HTTPS_CERTIFICATE_FILE=/opt/keycloak/conf/testkc.crt
KC_HTTPS_CERTIFICATE_KEY_FILE=/opt/keycloak/conf/testkc.key
KC_HTTPS_KEY_STORE_TYPE=jks
KC_HTTPS_KEY_STORE_FILE=/opt/keycloak/conf/testkc.jks
KC_HTTPS_TRUST_STORE_TYPE=jks
KC_HTTPS_TRUST_STORE_FILE=/opt/keycloak/conf/testkc.jks
KC_HTTPS_PORT=9000
KC_HTTP_MANAGEMENT_PORT=9000
KC_LOG=file
KC_LOG_LEVEL=INFO
KC_CACHE=localVersion26.1.2 Regression
Expected behaviorIf keycloak service is up, Actual behaviorIf keycloak service is up, How to Reproduce?Set while true; do curl -k https://testkc:9000/management/health; echo; sleep 1; doneAnything else?No response |
Replies: 2 comments 7 replies
|
After looking at this a little more, it seems better to start as a discussion rather than an issue. There is nothing in Keycloak, nor Quarkus relative to the management interface that would cause a 404 for a specific number of requests. It's odd in general that you are seeing 404 from the health endpoint at all - that suggests something else may be in play, possibly a dns issue with testkc? Can you try simplifying what you have done to isolate where the 404 is coming from - can you for example reproduce this without running as a service? |
|
When I start Keycloak, only for the first successful request do I receive the "SUCCESS" message that you sent. Also, for the first request that returns 404, the "CLIENT_ERROR" message that you sent appears in the log. But with every subsequent 404 request, the following is additionally logged: And with every successful curl request, the following is additionally logged: |
|
Sorry, I was too focused on the relative paths and completely missed in my reproducer that you are setting both the https port and the management port to 9000. This is where the problem lies. We had a similar issue a while back when the http and https ports were set to the value - there's now a validation for that quarkusio/quarkus#39289 Can you retry your scenario with distinct ports? If things start working for you, then please create a Keycloak issue to add this validation and we'll use that to get something into quarkus. |
|
When I set a separate port for management, it works as expected. Is the fact that I set both https_port and http_management_port to the same value (9000) a misuse on my part and it is not designed to work that way? |
Yes - quarkus routing of http vs https or management vs non-management is implicitly based upon having different ports. So it's missing a validation that would have made the problem immediately clear. If you want management stuff on the same ports as regular keycloak access, for now there is still https://www.keycloak.org/server/management-interface#_disable_management_interface |
|
Created quarkusio/quarkus#46629 to address this from the quarkus side. |
Yes - quarkus routing of http vs https or management vs non-management is implicitly based upon having different ports. So it's missing a validation that would have made the problem immediately clear.
If you want management stuff on the same ports as regular keycloak access, for now there is still https://www.keycloak.org/server/management-interface#_disable_management_interface