camunda/camunda-platform

Healthcheck with --no-check-certificate creates ssl-client zombies

McAlm opened this issue · 4 comments

McAlm commented

wget -q --tries=1 --no-check-certificate --spider https://localhost:8082/actuator/health

the param --no-check-certificate is needed since wget has no option to pass by trusted CA's. Every call (every 5 secs) creates a zombie of ssl-client:

/app # ps; date; wget -q --tries=1 --no-check-certificate --spider https://localhost:8082/actuator/health; date; ps
PID   USER     TIME  COMMAND
    1 root      0:41 java -jar identity.jar
   75 root      0:00 sh
   82 root      0:00 [ssl_client]
   91 root      0:00 [ssl_client]
   96 root      0:00 sh
  128 root      0:00 [ssl_client]
  139 root      0:00 [ssl_client]
  145 root      0:00 [ssl_client]
  149 root      0:00 ps
Thu Aug 17 17:22:16 CEST 2023
Thu Aug 17 17:22:16 CEST 2023
PID   USER     TIME  COMMAND
    1 root      0:41 java -jar identity.jar
   75 root      0:00 sh
   82 root      0:00 [ssl_client]
   91 root      0:00 [ssl_client]
   96 root      0:00 sh
  128 root      0:00 [ssl_client]
  139 root      0:00 [ssl_client]
  145 root      0:00 [ssl_client]
  152 root      0:00 [ssl_client]
  155 root      0:00 ps

This leads to an OOM after approximately 12 hours. So in such a scenario wget is not the optimal solution, but curl is not part of the containers. Any other options to do the health check?

I'm confused. By default, the docker compose file does not run with https, so I'm not sure why your system is doing healthchecks on https, when I see in the docker compose file on main branch that it is using http. Did you make any changes to the compose file?

McAlm commented

Hello @jessesimpson36 : Yes, the customer made changes to run C8 via docker-compose in their lab environment (later in production). All web-apps are secured by TLS.

I see. We do not recommend running C8 via docker-compose in production. I see the use-case for docker compose as mostly if a customer wants to try out C8 before taking the time to learn and deploy via kubernetes or before using the SaaS version. I see the SaaS free trial clusters as being a similar use case as well.

If a customer is willing to make custom changes to the compose file to run https and are modifying the healthchecks to add --no-check-certificate, then I don't think this issue has anything to do with our docker-compose configuration which by default is HTTP. The customer could set up their own trusted SSL certificate, switch back to HTTP, or remove the healthcheck entirely.

Please let me know if I'm wrong in my assessment, or if there's any extra context I'm missing.

Closing this issue since there have been no updates for a while.