-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JAVA_TOOL_OPTIONS environment expansion added in 0.112.0 crash loops java applications while running on gke #3463
Comments
hi @ryanohnemus this is not enough information to debug. Could you please share your deployment/pod specification? |
hi @pavolloffay, I ran through a few different versions of this setup and found this specifically is due to different handling of ENV vars within GKE vs normal k8s. (As far as a deployment i was using the image: azul/zulu-openjdk:8-jre-latest with a command of The change from #1814 appears to add a 2nd environment variable of the exact same name.
However when running on GKE's 1.31 version, it seems you are not allowed to have multiple env vars of the same name. These get collapsed when the pod is created and you have a pod that only has the last defined variable:
This results in java attempting env expansion and failing with the Can the original solution be updated to modify the JAVA_TOOL_OPTIONS env var in-place without this duplicate named entry being created? |
Hi @pavolloffay @ryanohnemus ! Duplicate env vars don't work for us either (aws eks v1.28.13). Instead of two JAVA_TOOL_OPTIONS, there is only one JAVA_TOOL_OPTIONS in the pod resource with this value
Which causes the pods to crash 😞 I think there is some kind of mutating webhook in our cluster that is causing such behaviour. I haven't identified which one, but I can investigate this later. |
Yes, experiencing the same issue for some of my java apps in the most recent version of the operator. Duplicate environment variables seams to be stripped out and only the one with reference to the original exists. For us this happens when the deployment already have You can test this yourself with a deployment/pod with the following env:
For this case I suggest bringing back the original solution by modify the JAVA_TOOL_OPTIONS env var in-place without this duplicate named entry being created 🙏🏻 |
Component(s)
auto-instrumentation
What happened?
Description
After upgrading the otel-operator to version 0.112.0, java8 containers that use auto-instrumentation with
inject-java
attributes fail to start with the following error:I believe this is due to #1814 being patched in the 0.112.0 version.
Steps to Reproduce
Attempt to run a java8 application using autoinstrumentation after upgrading to otel-operator 0.112.0. The java container will crash loop with the above error.
Expected Result
Auto-instrumentation to load the javaagent without crashing the java application.
Actual Result
Java8 container crash loops.
Kubernetes Version
1.31.0
Operator version
0.112.0
Collector version
0.112.0
Environment information
Environment
Java Zulu JRE 8.0.432-1
Log output
Additional context
Reverting to 0.107.0 of the otel-operator resolves the issue.
The text was updated successfully, but these errors were encountered: