-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins ver. 2.218
EnvInject API Plugin 1.7
Environment Injector Plugin 2.3.0
Hi,
After starting Jenkins, there is displayed "An illegal reflective access" warning in console.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.En
vInjectMasterEnvVarsSetter to field java.lang.reflect.Field.modifiers
WARNING: Please consider reporting this to the maintainers of org.jenkinsci.plug
ins.envinject.service.EnvInjectMasterEnvVarsSetter
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflect
ive access operations
WARNING: All illegal access operations will be denied in a future release
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
[JENKINS-60891] An illegal reflective access from EnvInject plugin
I wanted to provide an update on this ticket since there are a large number of duplicate tickets being filed as people migrate to Java 17.
Fixing this issue properly would require changes to Jenkins core (a new API to allow mutation of per-node environment variables) and a number of plugins (migrate any consumers of the old API to the new one). We would likely not oppose such a change if someone volunteered to do it. As of today, nobody has volunteered to work on such a change.
In the meantime, there are two workarounds for affected users:
- If all you need to do is update an existing environment variable (such as PATH) but have no need to add or remove environment variables, upgrade to https://github.com/jenkinsci/envinject-plugin/releases/tag/2.919.v009a_a_1067cd0.
- If you need to add (i.e., set) or remove (i.e., unset) environment variables, consider unchecking Prepare jobs environment or Unset System Environment Variables in the envinject plugin (i.e., reduce or eliminate usage of the envinject plugin), and instead implement this in your shell by starting the agent process (i.e., the process started by running java -jar agent.jar […]) in the desired environment (e.g., clear the environment and define FOO with env - FOO=BAR java -jar agent.jar […]). In general, mutating environment variables in a Unix process is tricky business, and it is always more reliable to start the process with the desired environment than to try to change the environment later. Changing the environment after a Unix process has started often results in race conditions, and the envinject plugin is no exception.
If you need to add (set) or remove (unset) environment variables and must do this using the envinject plugin, then specify the --add-opens JVM option for your agent:
- When you have outbound agents that connect via SSH you need to specify the JVM options on the agent configuration page:
https://issues.jenkins.io/secure/attachment/63013/63013_image-2024-07-25-22-51-30-714.png
- For inbound agents you have to add the argument to the JVM there. It should look like this:
java --add-opens java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED -jar agent.jar -url http://localhost:9090/ -secret <secret> -name inbound -workDir <workdir>
(Thanks to mawinter69 for these instructions.)
Basil Crow
added a comment - - edited I wanted to provide an update on this ticket since there are a large number of duplicate tickets being filed as people migrate to Java 17.
Fixing this issue properly would require changes to Jenkins core (a new API to allow mutation of per-node environment variables) and a number of plugins (migrate any consumers of the old API to the new one). We would likely not oppose such a change if someone volunteered to do it. As of today, nobody has volunteered to work on such a change.
In the meantime, there are two workarounds for affected users:
If all you need to do is update an existing environment variable (such as PATH ) but have no need to add or remove environment variables, upgrade to https://github.com/jenkinsci/envinject-plugin/releases/tag/2.919.v009a_a_1067cd0 .
If you need to add (i.e., set) or remove (i.e., unset) environment variables, consider unchecking Prepare jobs environment or Unset System Environment Variables in the envinject plugin (i.e., reduce or eliminate usage of the envinject plugin), and instead implement this in your shell by starting the agent process (i.e., the process started by running java -jar agent.jar […] ) in the desired environment (e.g., clear the environment and define FOO with env - FOO=BAR java -jar agent.jar […] ). In general, mutating environment variables in a Unix process is tricky business , and it is always more reliable to start the process with the desired environment than to try to change the environment later. Changing the environment after a Unix process has started often results in race conditions, and the envinject plugin is no exception.
If you need to add (set) or remove (unset) environment variables and must do this using the envinject plugin, then specify the --add-opens JVM option for your agent:
When you have outbound agents that connect via SSH you need to specify the JVM options on the agent configuration page:
https://issues.jenkins.io/secure/attachment/63013/63013_image-2024-07-25-22-51-30-714.png
For inbound agents you have to add the argument to the JVM there. It should look like this:
java --add-opens java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED -jar agent.jar -url http: //localhost:9090/ -secret <secret> -name inbound -workDir <workdir>
(Thanks to mawinter69 for these instructions.) All comments
Is there any progress on this issue? Issue reproduced with following specification:
WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to method java.lang.Class.getDeclaredFields0(boolean)
Jenkins 2.361.4
| java.runtime.version | 11.0.14+9 |
| java.vendor.version | Temurin-11.0.14+9 |
| java.vendor | Eclipse Adoptium |
Helcio Mayor
added a comment - - edited Is there any progress on this issue? Issue reproduced with following specification:
WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to method java.lang.Class.getDeclaredFields0(boolean)
Jenkins 2.361.4
java.runtime.version
11.0.14+9
java.vendor.version
Temurin-11.0.14+9
java.vendor
Eclipse Adoptium
Environment Injector PluginVersion2.881.v37c62073ff97
EnvInject API PluginVersion1.199.v3ce31253ed13 I can reproduce as well. I see the following warning message displayed in the build agent connection log (SSH connection, Windows build agent, Java 11).:
WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to method java.lang.Class.getDeclaredFields0(boolean) WARNING: Please consider reporting this to the maintainers of org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release
Same here after upgrading controller (2.414.3) and inbound agent to JDK17. Didn't appearwhen both running on Java11
We started to see
java.lang.reflect.InaccessibleObjectException: Unable to make private native java.lang.reflect.Field[] java.lang.Class.getDeclaredFields0(boolean) accessible: module java.base does not "opens java.lang" to unnamed module @28c6c0e9 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Unknown Source) at java.base/java.lang.reflect.Method.setAccessible(Unknown Source) at org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter.getModifiers(EnvInjectMasterEnvVarsSetter.java:29) at org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter.call(EnvInjectMasterEnvVarsSetter.java:55) at org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter.call(EnvInjectMasterEnvVarsSetter.java:19) at hudson.remoting.UserRequest.perform(UserRequest.java:211) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:377) at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78) at java.base/java.util.concurrent.FutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:127) at java.base/java.lang.Thread.run(Unknown Source) Agent successfully connected and online
on connection logs
John
added a comment - Confirming that I am receiving this error as well:
INFO: Connected
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to method java.lang.Class.getDeclaredFields0(boolean)
WARNING: Please consider reporting this to the maintainers of org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
John
added a comment - Confirming that I am receiving this error as well:
INFO: Connected
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter to method java.lang.Class.getDeclaredFields0(boolean)
WARNING: Please consider reporting this to the maintainers of org.jenkinsci.plugins.envinject.service.EnvInjectMasterEnvVarsSetter
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release I wanted to provide an update on this ticket since there are a large number of duplicate tickets being filed as people migrate to Java 17.
Fixing this issue properly would require changes to Jenkins core (a new API to allow mutation of per-node environment variables) and a number of plugins (migrate any consumers of the old API to the new one). We would likely not oppose such a change if someone volunteered to do it. As of today, nobody has volunteered to work on such a change.
In the meantime, there are two workarounds for affected users:
- If all you need to do is update an existing environment variable (such as PATH) but have no need to add or remove environment variables, upgrade to https://github.com/jenkinsci/envinject-plugin/releases/tag/2.919.v009a_a_1067cd0.
- If you need to add (i.e., set) or remove (i.e., unset) environment variables, consider unchecking Prepare jobs environment or Unset System Environment Variables in the envinject plugin (i.e., reduce or eliminate usage of the envinject plugin), and instead implement this in your shell by starting the agent process (i.e., the process started by running java -jar agent.jar […]) in the desired environment (e.g., clear the environment and define FOO with env - FOO=BAR java -jar agent.jar […]). In general, mutating environment variables in a Unix process is tricky business, and it is always more reliable to start the process with the desired environment than to try to change the environment later. Changing the environment after a Unix process has started often results in race conditions, and the envinject plugin is no exception.
If you need to add (set) or remove (unset) environment variables and must do this using the envinject plugin, then specify the --add-opens JVM option for your agent:
- When you have outbound agents that connect via SSH you need to specify the JVM options on the agent configuration page:
https://issues.jenkins.io/secure/attachment/63013/63013_image-2024-07-25-22-51-30-714.png
- For inbound agents you have to add the argument to the JVM there. It should look like this:
java --add-opens java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED -jar agent.jar -url http://localhost:9090/ -secret <secret> -name inbound -workDir <workdir>
(Thanks to mawinter69 for these instructions.)
Basil Crow
added a comment - - edited I wanted to provide an update on this ticket since there are a large number of duplicate tickets being filed as people migrate to Java 17.
Fixing this issue properly would require changes to Jenkins core (a new API to allow mutation of per-node environment variables) and a number of plugins (migrate any consumers of the old API to the new one). We would likely not oppose such a change if someone volunteered to do it. As of today, nobody has volunteered to work on such a change.
In the meantime, there are two workarounds for affected users:
If all you need to do is update an existing environment variable (such as PATH ) but have no need to add or remove environment variables, upgrade to https://github.com/jenkinsci/envinject-plugin/releases/tag/2.919.v009a_a_1067cd0 .
If you need to add (i.e., set) or remove (i.e., unset) environment variables, consider unchecking Prepare jobs environment or Unset System Environment Variables in the envinject plugin (i.e., reduce or eliminate usage of the envinject plugin), and instead implement this in your shell by starting the agent process (i.e., the process started by running java -jar agent.jar […] ) in the desired environment (e.g., clear the environment and define FOO with env - FOO=BAR java -jar agent.jar […] ). In general, mutating environment variables in a Unix process is tricky business , and it is always more reliable to start the process with the desired environment than to try to change the environment later. Changing the environment after a Unix process has started often results in race conditions, and the envinject plugin is no exception.
If you need to add (set) or remove (unset) environment variables and must do this using the envinject plugin, then specify the --add-opens JVM option for your agent:
When you have outbound agents that connect via SSH you need to specify the JVM options on the agent configuration page:
https://issues.jenkins.io/secure/attachment/63013/63013_image-2024-07-25-22-51-30-714.png
For inbound agents you have to add the argument to the JVM there. It should look like this:
java --add-opens java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED -jar agent.jar -url http: //localhost:9090/ -secret <secret> -name inbound -workDir <workdir>
(Thanks to mawinter69 for these instructions.) 
I've run into this as well: java version openjdk-11+28_linux-x64, OS CentOS Linux release 8.2.2004 (Core). remoting jar version 4.11.2, jenkins version 2.330