Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-67000

JavaWebStart agents cannot connect due to AccessControlException

    • 2.335,2.332.1

      This week after the jenkins update of 2.317 and to 2.318 , my agent machine (windows 10) start getting terminated again and again after connected

       

      As normally I use jnlp file right click to launch , the jenkins agent windows appears and I can see Connected but within few seconds its got Terminated

       

      I went into the remoting folder to check out the logs and it prompts this error

       

      Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "hudson.util.RingBufferLogHandler.defaultSize" "read")

       

      Agent Java version : OpenJDK 1.8.0 301
      Jenkins version : Jenkins 2.318

      I am using Openwebstart for jnlp

       

      Complete log message (agent machine)

      Okt 26, 2021 9:53:03 AM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve
      INFORMATION: Remoting server accepts the following protocols: [JNLP4-connect, Ping]
      Okt 26, 2021 9:53:03 AM org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader run
      INFORMATION: Waiting for ProtocolStack to start.
      Okt 26, 2021 9:53:08 AM hudson.remoting.UserRequest perform
      WARNUNG: LinkageError while performing UserRequest:hudson.slaves.SlaveComputer$SlaveInitializer@6cfcc55d
      java.lang.ExceptionInInitializerError
      at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1042)
      at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1033)
      at hudson.remoting.UserRequest.perform(UserRequest.java:211)
      at hudson.remoting.UserRequest.perform(UserRequest.java:54)
      at hudson.remoting.Request$2.run(Request.java:376)
      at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:122)
      at java.lang.Thread.run(Unknown Source)
      Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "hudson.util.RingBufferLogHandler.defaultSize" "read")
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
      at java.lang.System.getProperty(Unknown Source)
      at java.lang.Integer.getInteger(Unknown Source)
      at java.lang.Integer.getInteger(Unknown Source)
      at hudson.util.RingBufferLogHandler.<clinit>(RingBufferLogHandler.java:39)
      ... 11 more

       

          [JENKINS-67000] JavaWebStart agents cannot connect due to AccessControlException

          Mark Waite added a comment - - edited

          I can't duplicate the problem you're reporting. I have a Windows 10 agent connected by running a local batch script that runs the Java command with remoting.jar to connect to my Docker based controller running Jenkins 2.318. No loss of connection. No issues reported.

          I'm running remoting 4.10 on my Windows agent. What version of remoting are you running?

          I've now updated to use the 4.11 agent.jar with remoting.jar 4.11. No issues detected in any of the cases yet.

          The version node monitor plugin will show the version of remoting used by each of your agents. It will also allow you to enforce that agent remoting must match the remoting version on your controller.

          Mark Waite added a comment - - edited I can't duplicate the problem you're reporting. I have a Windows 10 agent connected by running a local batch script that runs the Java command with remoting.jar to connect to my Docker based controller running Jenkins 2.318. No loss of connection. No issues reported. I'm running remoting 4.10 on my Windows agent. What version of remoting are you running? I've now updated to use the 4.11 agent.jar with remoting.jar 4.11. No issues detected in any of the cases yet. The version node monitor plugin will show the version of remoting used by each of your agents. It will also allow you to enforce that agent remoting must match the remoting version on your controller.

          Bilawal Ali added a comment -

          markewaite first of all thankyou so much for your reply

          Can you please guide me how to check the remoting version , please dont be annoyed for my silly/basic questions as I am very new to jenkins world

           

          I am pretty sure that there is sort of mis match of JDK versions from my hand trying to figure out

           

          Thanks

          Bilawal Ali added a comment - markewaite first of all thankyou so much for your reply Can you please guide me how to check the remoting version , please dont be annoyed for my silly/basic questions as I am very new to jenkins world   I am pretty sure that there is sort of mis match of JDK versions from my hand trying to figure out   Thanks

          Mark Waite added a comment -

          The "Manage Jenkins" -> "System Information" page will show the Java information and operating system of the controller. The "System Information" page of the agent will show the Java information and operating system of the agent.

          The easiest way to see the remoting version number of an agent is to install the version node monitor plugin and then look at the remoting version column in the table of agents at the /computer/ URL on your Jenkins controller. I also have the Java version visible in a column on that table after installing the version node monitor plugin.

          Mark Waite added a comment - The "Manage Jenkins" -> "System Information" page will show the Java information and operating system of the controller. The "System Information" page of the agent will show the Java information and operating system of the agent. The easiest way to see the remoting version number of an agent is to install the version node monitor plugin and then look at the remoting version column in the table of agents at the /computer/ URL on your Jenkins controller. I also have the Java version visible in a column on that table after installing the version node monitor plugin.

          Bilawal Ali added a comment -

          Hey Mark thanks for your detailed reply

           

          I just checked and I also have remoting version 4.11 I have installed that node monitor plugin and configure that accordingly mentioned on jenkins website

          Still i am getting the same error log , I also upgraded JDK 11 on both of my agent machine and installed OpenWebStart for jnlp file but nothing changes and keep getting the same error that agent connected and than immediately Terminated and this cycle is continuing again and again

           

           

          Bilawal Ali added a comment - Hey Mark thanks for your detailed reply   I just checked and I also have remoting version 4.11 I have installed that node monitor plugin and configure that accordingly mentioned on jenkins website Still i am getting the same error log , I also upgraded JDK 11 on both of my agent machine and installed OpenWebStart for jnlp file but nothing changes and keep getting the same error that agent connected and than immediately Terminated and this cycle is continuing again and again    

          Mark Waite added a comment - - edited

          You may want to check with other Windows 10 machines to see if they have the same problem. You might consider checking the network configuration of that machine to see if it has something interesting configured in Windows firewall that might block ports or prevent access. You might consider checking the Windows logs to see if there is any indication why the network connection is being interrupted. Maybe an aggressive virus scanner is deciding that the Windows 10 machine is not allowed to talk over the network.

          You might check the file system permissions of the files on that computer to see if the files where the agent creates its logs have someone been locked so that the agent is not able to write them. You might check that there is not a second agent already running on the machine that might be using the same location for its configuration.

          Mark Waite added a comment - - edited You may want to check with other Windows 10 machines to see if they have the same problem. You might consider checking the network configuration of that machine to see if it has something interesting configured in Windows firewall that might block ports or prevent access. You might consider checking the Windows logs to see if there is any indication why the network connection is being interrupted. Maybe an aggressive virus scanner is deciding that the Windows 10 machine is not allowed to talk over the network. You might check the file system permissions of the files on that computer to see if the files where the agent creates its logs have someone been locked so that the agent is not able to write them. You might check that there is not a second agent already running on the machine that might be using the same location for its configuration.

          Bilawal Ali added a comment -

          For Network Configuration / Windows Firewall : I just checked the setting nothing unusual or any especial settings has been done to block any port or access

          I just disable all virus scanner from my remote machine (agent) and still issue persist , My remote machine currently only have one agent at a time which is asking to connect to master there is no any agent already there only one agent per machine.

          I just reinstall the windows set the jenkins again and still having same issue My agent connected but then terminated again

           

          Can I show you the demo if it is possible ?

          Bilawal Ali added a comment - For Network Configuration / Windows Firewall : I just checked the setting nothing unusual or any especial settings has been done to block any port or access I just disable all virus scanner from my remote machine (agent) and still issue persist , My remote machine currently only have one agent at a time which is asking to connect to master there is no any agent already there only one agent per machine. I just reinstall the windows set the jenkins again and still having same issue My agent connected but then terminated again   Can I show you the demo if it is possible ?

          Mark Waite added a comment -

          No, I'm sorry, but I'm not willing to spend the time to have you demonstrate the problem. There are commercial organizations that sell products based on Jenkins and are willing to provide support services for their products. Since I am unable to duplicate the problem, I recommend that we close this issue as "Cannot reproduce" and that you open a topic on https://community.jenkins.io that describes your configuration in detail and asks for help with the diagnosis.

          Mark Waite added a comment - No, I'm sorry, but I'm not willing to spend the time to have you demonstrate the problem. There are commercial organizations that sell products based on Jenkins and are willing to provide support services for their products. Since I am unable to duplicate the problem, I recommend that we close this issue as "Cannot reproduce" and that you open a topic on https://community.jenkins.io that describes your configuration in detail and asks for help with the diagnosis.

          Mark Waite added a comment -

          Closing as "cannot reproduce". Further exploration and questions need to happen in the user mailing list or on community.jenkins.io.

          Mark Waite added a comment - Closing as "cannot reproduce". Further exploration and questions need to happen in the user mailing list or on community.jenkins.io.

          Nick added a comment -

          I'm running into the same issue

          Nick added a comment - I'm running into the same issue

          Mark Waite added a comment -

          bruntmyer29 can you provide enough details so that others can duplicate the issue?

          Reopening the issue is a good first step because it tells others that you've seen the problem. However, if others are like me, they won't spend further effort on the issue until there is new information that might hint why most users do not see the issue. I don't see the issue. As far as I can tell, most others don't see the issue. Can you see the issue on a separately installed instance?

          Mark Waite added a comment - bruntmyer29 can you provide enough details so that others can duplicate the issue? Reopening the issue is a good first step because it tells others that you've seen the problem. However, if others are like me, they won't spend further effort on the issue until there is new information that might hint why most users do not see the issue. I don't see the issue. As far as I can tell, most others don't see the issue. Can you see the issue on a separately installed instance?

          Nick added a comment -

          I'm not sure what to do. I added logs from when I successfully started the node by running from a cmd line (remoting.log.0_run_via_agent.jar.log) and a log from when the jenkins-agent.jnlp terminates (remoting.log.0_run_via_jenkins-agent.jnlp.log). I tried deleting the node and then recreating the node and jenkins-agent.jnlp file but it still keeps terminating. I'm running Java Version 8 Update 202 (build 1.8.0_202-b08) which is the same as other nodes in my system which are working so I'm not sure what else I can do to debug this? If there is, let me know?

          Thanks

          Nick added a comment - I'm not sure what to do. I added logs from when I successfully started the node by running from a cmd line (remoting.log.0_run_via_agent.jar.log) and a log from when the jenkins-agent.jnlp terminates (remoting.log.0_run_via_jenkins-agent.jnlp.log). I tried deleting the node and then recreating the node and jenkins-agent.jnlp file but it still keeps terminating. I'm running Java Version 8 Update 202 (build 1.8.0_202-b08) which is the same as other nodes in my system which are working so I'm not sure what else I can do to debug this? If there is, let me know? Thanks

          Mark Waite added a comment -

          I doubt it will change anything, but Java 8u202 is almost 3 years old. JDK patch releases happen about every three months. That means your Java version is at least 10 patch releases out of date. The current Java 8 patch release is 8u312.

          I doubt it will change the behavior, but you may want to install Java 8u312 on another computer, install Jenkins, and configure an agent using Java 8u312. If that new installation shows the same behavior, if may give you ideas to suggest which difference in your installation result cause the issue to be visible. If it does not show the issue, that may suggest that it would be worth switching to the newer JDK patch.

          Mark Waite added a comment - I doubt it will change anything, but Java 8u202 is almost 3 years old. JDK patch releases happen about every three months. That means your Java version is at least 10 patch releases out of date. The current Java 8 patch release is 8u312. I doubt it will change the behavior, but you may want to install Java 8u312 on another computer, install Jenkins, and configure an agent using Java 8u312. If that new installation shows the same behavior, if may give you ideas to suggest which difference in your installation result cause the issue to be visible. If it does not show the issue, that may suggest that it would be worth switching to the newer JDK patch.

          Nick added a comment -

          Okay, since this node was working about a month ago I just figured it had something to do with the master / built-in node switch change that recently happened in Jenkins. I don't have much control over Java at my organization and other nodes in the system are working with the same Java version. The node is working by running through the command line so I'll probably just run with it that way for now if you do want to re -close this ticket. Thanks though.

          Nick added a comment - Okay, since this node was working about a month ago I just figured it had something to do with the master / built-in node switch change that recently happened in Jenkins. I don't have much control over Java at my organization and other nodes in the system are working with the same Java version. The node is working by running through the command line so I'll probably just run with it that way for now if you do want to re -close this ticket. Thanks though.

          Bilawal Ali added a comment -

          markewaite I switched to new JDK patch the latest one JDK 11 the stable version unfortunately it does not make any difference to the error , it do connects but then immediately terminated and when I went to logs in remoting folder i got this same error so the point regarding switching to new JDK patch is some how same if i used old or new the error keeps popping.

          Bilawal Ali added a comment - markewaite I switched to new JDK patch the latest one JDK 11 the stable version unfortunately it does not make any difference to the error , it do connects but then immediately terminated and when I went to logs in remoting folder i got this same error so the point regarding switching to new JDK patch is some how same if i used old or new the error keeps popping.

          Bilawal Ali added a comment -

          bruntmyer29 I also applied the other method to connect my nodes with master , I wrote the batch file which have those magic lines in it where agent.jar and secret files are define since this error I am not using jnlp method to launch my agent but I used cmd option to get my node online

           

          But , I am curious and willing to know what exactly is the cause of this error and why it keep popping it

          Bilawal Ali added a comment - bruntmyer29 I also applied the other method to connect my nodes with master , I wrote the batch file which have those magic lines in it where agent.jar and secret files are define since this error I am not using jnlp method to launch my agent but I used cmd option to get my node online   But , I am curious and willing to know what exactly is the cause of this error and why it keep popping it

          Dawid Pichen added a comment - - edited

          Hello there,

          I am experiencing exactly the same issue on three different W10 machines with the latest Java installed:

          d:\>java -version
           java version "1.8.0_311"
           Java(TM) SE Runtime Environment (build 1.8.0_311-b11)
           Java HotSpot(TM) 64-Bit Server VM (build 25.311-b11, mixed mode)
          

          In remoting.log.0 file I see this:

          gru 20, 2021 9:13:43 AM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve
          INFO: Remoting server accepts the following protocols: [JNLP4-connect, Ping]
          gru 20, 2021 9:13:43 AM org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader run
          INFO: Waiting for ProtocolStack to start.
          gru 20, 2021 9:13:47 AM hudson.remoting.UserRequest perform
          WARNING: LinkageError while performing UserRequest:hudson.slaves.SlaveComputer$SlaveInitializer@29462704
          java.lang.ExceptionInInitializerError
          	at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1050)
          	at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1041)
          	at hudson.remoting.UserRequest.perform(UserRequest.java:211)
          	at hudson.remoting.UserRequest.perform(UserRequest.java:54)
          	at hudson.remoting.Request$2.run(Request.java:376)
          	at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
          	at java.util.concurrent.FutureTask.run(Unknown Source)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          	at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:122)
          	at java.lang.Thread.run(Unknown Source)
          Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "hudson.util.RingBufferLogHandler.defaultSize" "read")
          	at java.security.AccessControlContext.checkPermission(Unknown Source)
          	at java.security.AccessController.checkPermission(Unknown Source)
          	at java.lang.SecurityManager.checkPermission(Unknown Source)
          	at com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source)
          	at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
          	at java.lang.System.getProperty(Unknown Source)
          	at java.lang.Integer.getInteger(Unknown Source)
          	at java.lang.Integer.getInteger(Unknown Source)
          	at hudson.util.RingBufferLogHandler.<clinit>(RingBufferLogHandler.java:39)
          	... 11 more
          

          Perhaps indeed it is somehow related to recent name change of the master node to „Built-In Node”?
          Jenkins master is at version 2.319.1.

           

          Dawid Pichen added a comment - - edited Hello there, I am experiencing exactly the same issue on three different W10 machines with the latest Java installed: d:\>java -version java version "1.8.0_311" Java(TM) SE Runtime Environment (build 1.8.0_311-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.311-b11, mixed mode) In remoting.log.0 file I see this: gru 20, 2021 9:13:43 AM org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver resolve INFO: Remoting server accepts the following protocols: [JNLP4-connect, Ping] gru 20, 2021 9:13:43 AM org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader run INFO: Waiting for ProtocolStack to start. gru 20, 2021 9:13:47 AM hudson.remoting.UserRequest perform WARNING: LinkageError while performing UserRequest:hudson.slaves.SlaveComputer$SlaveInitializer@29462704 java.lang.ExceptionInInitializerError at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1050) at hudson.slaves.SlaveComputer$SlaveInitializer.call(SlaveComputer.java:1041) at hudson.remoting.UserRequest.perform(UserRequest.java:211) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:376) at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:122) at java.lang. Thread .run(Unknown Source) Caused by: java.security.AccessControlException: access denied ( "java.util.PropertyPermission" "hudson.util.RingBufferLogHandler.defaultSize" "read" ) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang. SecurityManager .checkPermission(Unknown Source) at com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) at java.lang. SecurityManager .checkPropertyAccess(Unknown Source) at java.lang. System .getProperty(Unknown Source) at java.lang. Integer .getInteger(Unknown Source) at java.lang. Integer .getInteger(Unknown Source) at hudson.util.RingBufferLogHandler.<clinit>(RingBufferLogHandler.java:39) ... 11 more Perhaps indeed it is somehow related to recent name change of the master node to „Built-In Node”? Jenkins master is at version 2.319.1.  

          Bilawal Ali added a comment -

          dawidpichen when you connect with agent.jar is it connected successfully via command prompt ?

          Bilawal Ali added a comment - dawidpichen when you connect with agent.jar is it connected successfully via command prompt ?

          Dawid Pichen added a comment -

          Hiya testengineer!

          No, when I connect with agent.jar via command prompt, issue does not occur. Only in the GUI agent.

          Dawid Pichen added a comment - Hiya testengineer ! No, when I connect with agent.jar via command prompt, issue does not occur. Only in the GUI agent.

          Bilawal Ali added a comment -

          dawidpichen exactly same with me since this issue arrived I am using agent.jar via cmd and it works but whenever I tried to connect it via GUI it wont . Are you using OpenWebStart or JavaWebStart?

          Bilawal Ali added a comment - dawidpichen exactly same with me since this issue arrived I am using agent.jar via cmd and it works but whenever I tried to connect it via GUI it wont . Are you using OpenWebStart or JavaWebStart?

          Dawid Pichen added a comment -

          testengineer: JavaWebStart as per attached screenshot.

          Attn. markewaite: similar problem occurs on a machine with Windows Server 2012 R2, so it is not Windows 10 specific issue.

          Dawid Pichen added a comment - testengineer : JavaWebStart as per attached screenshot. Attn. markewaite : similar problem occurs on a machine with Windows Server 2012 R2, so it is not Windows 10 specific issue.

          Mark Waite added a comment - - edited

          dawidpichen if you switch from Java Web Start to instead launch from a batch command using the command prompt, does it resolve the issue? That may allow you to continue running from the Windows Desktop

          If you need the Windows agent running as a service, have you considered installing the Windows OpenSSH server on the agent machine so that you could manage the agents with OpenSSH? I doubt that Windows OpenSSH server is available for Windows Server 2012, but you could check to be sure.

          Java Web Start is no longer included with Java 11 or Java 17.

          Mark Waite added a comment - - edited dawidpichen if you switch from Java Web Start to instead launch from a batch command using the command prompt, does it resolve the issue? That may allow you to continue running from the Windows Desktop If you need the Windows agent running as a service, have you considered installing the Windows OpenSSH server on the agent machine so that you could manage the agents with OpenSSH? I doubt that Windows OpenSSH server is available for Windows Server 2012, but you could check to be sure. Java Web Start is no longer included with Java 11 or Java 17.

          Bilawal Ali added a comment -

          Is there any update from jenkins side regarding the issue ? I just tried once again via jnlp file to connect my agent but does not works

          Bilawal Ali added a comment - Is there any update from jenkins side regarding the issue ? I just tried once again via jnlp file to connect my agent but does not works

          Mark Waite added a comment -

          testengineer I'm not sure what you are expecting as an "update from jenkins side regarding the issue".  Java web start has been dropped from Java 11 and is not included in Java 17.  I've not seen any effort in the last 12 months by Jenkins maintainers or contributors to propose changes that would alter or improve the behavior of Jenkins agents with Java Web Start.

          Same question to you as I asked to dawidpichen.  If you run the Jenkins agent from a batch command or a PowerShell command, does it resolve the issue?

          My Jenkins agent that runs rom a batch file on the Windows Desktop is running great with Jenkins 2.319.1 and with Jenkins 2.327.  I don't use Java Web Start from my Windows desktop because the batch file works and is supported with Java 11 and with current open source versions of Java 8.

          Mark Waite added a comment - testengineer  I'm not sure what you are expecting as an "update from jenkins side regarding the issue".  Java web start has been dropped from Java 11 and is not included in Java 17.  I've not seen any effort in the last 12 months by Jenkins maintainers or contributors to propose changes that would alter or improve the behavior of Jenkins agents with Java Web Start. Same question to you as I asked to dawidpichen .  If you run the Jenkins agent from a batch command or a PowerShell command, does it resolve the issue? My Jenkins agent that runs rom a batch file on the Windows Desktop is running great with Jenkins 2.319.1 and with Jenkins 2.327.  I don't use Java Web Start from my Windows desktop because the batch file works and is supported with Java 11 and with current open source versions of Java 8.

          Dawid Pichen added a comment -

          Hi testengineer and markewaite!

          First, happy New Year to you.

          Second, sorry for the late reply. Well, as explained in my answer from 20 December (https://issues.jenkins.io/browse/JENKINS-67000?focusedCommentId=417241&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-417241), the issue does not occur when Jenkins is started from the command line. It only happens when you try to launch the agent using Java Web Start.

          Even though Oracle has dropped Java Web Start, it is actually still being included with Java (javaws,exe) and works fine. Something must have happened to the Java Web Start agent recently. In my humble opinion it is neither the Java version issue nor Windows version issue, I think.

          It the JNLP is buggy now, it should be either fixed or completely removed from Jenkins, because „Java web start has been dropped from Java 11 and is not included in Java 17”.

          Mark: just give it a try using Java Web Start and you should see what I am talking about.

           

          Dawid Pichen added a comment - Hi testengineer and markewaite ! First, happy New Year to you. Second, sorry for the late reply. Well, as explained in my answer from 20 December ( https://issues.jenkins.io/browse/JENKINS-67000?focusedCommentId=417241&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-417241 ), the issue does not occur when Jenkins is started from the command line. It only happens when you try to launch the agent using Java Web Start. Even though Oracle has dropped Java Web Start, it is actually  still being included with Java (javaws,exe) and works fine. Something must have happened to the Java Web Start agent recently. In my humble opinion it is neither the Java version issue nor Windows version issue, I think. It the JNLP is buggy now, it should be either fixed or completely removed from Jenkins, because „Java web start has been dropped from Java 11 and is not included in Java 17”. Mark: just give it a try using Java Web Start and you should see what I am talking about.  

          Mark Waite added a comment -

          Even though Oracle has dropped Java Web Start, it is actually still being included with Java (javaws,exe) and works fine. Something must have happened to the Java Web Start agent recently. In my humble opinion it is neither the Java version issue nor Windows version issue, I think.

          I don't know what causes the issue. I'm not aware of any recent change to the Java web start agent other than possible upgrades of dependencies.

          It the JNLP is buggy now, it should be either fixed or completely removed from Jenkins, because „Java web start has been dropped from Java 11 and is not included in Java 17”.

          I used OpenWebStart successfully in the last experiment that I ran. I wasn't able to duplicate the problem. I'm unwilling to install Oracle Java because I can't do so without violating their license agreement. I'm not regularly using OpenWebStart because I prefer to start the Windows agent from OpenSSH (first choice) or from a batch file on the desktop (second choice).

          I'm not willing to lead the effort to remove the option to download a JNLP file. Other things are higher priority for me. If others feel strongly that they want to remove the option to download a JNLP file, I don't object.

          Mark Waite added a comment - Even though Oracle has dropped Java Web Start, it is actually still being included with Java (javaws,exe) and works fine. Something must have happened to the Java Web Start agent recently. In my humble opinion it is neither the Java version issue nor Windows version issue, I think. I don't know what causes the issue. I'm not aware of any recent change to the Java web start agent other than possible upgrades of dependencies. It the JNLP is buggy now, it should be either fixed or completely removed from Jenkins, because „Java web start has been dropped from Java 11 and is not included in Java 17”. I used OpenWebStart successfully in the last experiment that I ran. I wasn't able to duplicate the problem. I'm unwilling to install Oracle Java because I can't do so without violating their license agreement. I'm not regularly using OpenWebStart because I prefer to start the Windows agent from OpenSSH (first choice) or from a batch file on the desktop (second choice). I'm not willing to lead the effort to remove the option to download a JNLP file. Other things are higher priority for me. If others feel strongly that they want to remove the option to download a JNLP file, I don't object.

          Bilawal Ali added a comment -

          markewaite and dawidpichen  Thanks for your reply

          I so far have not faced any issue when I connect my agent via batch file and you may be right regarding the buggy nature of JNLP , therefore you can close this issue as we already have an alternate in the form of agent.jar connect via batch file for the jenkins agent

          markewaite glad to hear you got success via using OpenWebStart but unfortunately I did not , i tried couple of times with different settings but it has the same behaviour

          Thanks

          Bilawal Ali added a comment - markewaite and dawidpichen   Thanks for your reply I so far have not faced any issue when I connect my agent via batch file and you may be right regarding the buggy nature of JNLP , therefore you can close this issue as we already have an alternate in the form of agent.jar connect via batch file for the jenkins agent markewaite glad to hear you got success via using OpenWebStart but unfortunately I did not , i tried couple of times with different settings but it has the same behaviour Thanks

          Christoph added a comment - - edited

          We have the same issue in our environment. It probably started with the update from 2.289.1 to 2.319.2.

           

          A workaround that is working on our system is to replace the remoting...jar in the directory war\WEB-INF\lib (and then restart jenkins)

          Shipped with 2.139.2 we had the file remoting-4.11.2.jar.

          I have tried the old versions. The last one that is working is remoting-4.10.1.jar.

          So I guess a change in remoting 4.11 is causing this.

           

          When comparing 4.10.1 and 4.11. I found this pull request: https://github.com/jenkinsci/remoting/pull/481/files

          The file is: src/main/java/hudson/remoting/jnlp/Main.java 

          They removed a try-catch-block that basically disabled security exceptions.

          From what I can see from the pull request they just removed it because all the links that were mentioned are dead now.

          Maybe this try-catch-block just skipped the java.security.AccessControlException and now it doesn't anymore.

          Christoph added a comment - - edited We have the same issue in our environment. It probably started with the update from 2.289.1 to 2.319.2.   A workaround that is working on our system is to replace the remoting...jar in the directory war\WEB-INF\lib (and then restart jenkins) Shipped with 2.139.2 we had the file remoting-4.11.2.jar. I have tried the old versions. The last one that is working is remoting-4.10.1.jar. So I guess a change in remoting 4.11 is causing this.   When comparing 4.10.1 and 4.11. I found this pull request: https://github.com/jenkinsci/remoting/pull/481/files The file is: src/main/java/hudson/remoting/jnlp/Main.java   They removed a try-catch-block that basically disabled security exceptions. From what I can see from the pull request they just removed it because all the links that were mentioned are dead now. Maybe this try-catch-block just skipped the java.security.AccessControlException and now it doesn't anymore.

          Mark Waite added a comment -

          A workaround that is working on our system is to replace the remoting.jar in the directory war\WEB-INF\lib (and then restart jenkins)

          That's a scary workaround, since that removes the security fixes that were applied in remoting 4.11.2. It seems like a challenging workaround to maintain, since I would expect that file to be overwritten each time a new Jenkins version is installed.

          Mark Waite added a comment - A workaround that is working on our system is to replace the remoting.jar in the directory war\WEB-INF\lib (and then restart jenkins) That's a scary workaround, since that removes the security fixes that were applied in remoting 4.11.2. It seems like a challenging workaround to maintain, since I would expect that file to be overwritten each time a new Jenkins version is installed.

          Christoph added a comment -

          markewaite true it's not a nice workaround. I just wanted to help pointing to the root cause of this.

          Hoping the change that happened there gets fixed in the next version. (I have added some more details to the original post)

          Christoph added a comment - markewaite true it's not a nice workaround. I just wanted to help pointing to the root cause of this. Hoping the change that happened there gets fixed in the next version. (I have added some more details to the original post)

          Todd Vogl added a comment -

          We ended up going a different route:

           

          Downloaded the agent.jar into c:\Jenkins

          Put the java -jar agent.jar -jnlpUrl …….   Into a agent_start.cmd file located in the same directory

           

          Then created a "Jenkins Agent" task in Task Scheduler to RUN at startup

          In the action tab program/script is set to cmd

          add arguments:    /c c:\Jenkins\agent_start.cmd >C:\Jenkins\remoting\logs\remoting.log 2>&1 

          Start in: C:\Jenkins

           

          Then added some powershell scripts to start and stop the node.  You can’t start it from the Jenkins controller using this method shown above…. So that is a drawback… but You can from the server.  So I created 2 simple powershell scripts I put into Jenkins jobs.  This allows you to start and stop the node from Jenkins without granting access to the server directly or the need to log into the server just to start the node.

          Stop-ScheduledTask -TaskName "Jenkins Agent"

          Start-ScheduledTask -TaskName "Jenkins Agent"

           

          So far this has been working great

           

           

          Todd Vogl added a comment - We ended up going a different route:   Downloaded the agent.jar into c:\Jenkins Put the java -jar agent.jar -jnlpUrl …….   Into a agent_start.cmd file located in the same directory   Then created a "Jenkins Agent" task in Task Scheduler to RUN at startup In the action tab program/script is set to cmd add arguments:    /c c:\Jenkins\agent_start.cmd >C:\Jenkins\remoting\logs\remoting.log 2>&1  Start in: C:\Jenkins   Then added some powershell scripts to start and stop the node.  You can’t start it from the Jenkins controller using this method shown above…. So that is a drawback… but You can from the server.  So I created 2 simple powershell scripts I put into Jenkins jobs.  This allows you to start and stop the node from Jenkins without granting access to the server directly or the need to log into the server just to start the node. Stop-ScheduledTask -TaskName "Jenkins Agent" Start-ScheduledTask -TaskName "Jenkins Agent"   So far this has been working great    

          Jesse Glick added a comment -

          Reproduced in a trunk build using the Ubuntu package icedtea-netx. This is a genuine accidental regression. Certainly we do not recommend users use JWS to attach agents, but it remains an option offered in the GUI.

          Jesse Glick added a comment - Reproduced in a trunk build using the Ubuntu package icedtea-netx . This is a genuine accidental regression. Certainly we do not recommend users use JWS to attach agents, but it remains an option offered in the GUI.

          Jeff Thompson added a comment -

          a07855, that's a much better approach for a variety of reasons. One recommended enhancement. Your task should download the agent jar when the task starts and then run the agent. This allows it to keep updated with new agent / remoting versions, at least when the task runs.

          Jeff Thompson added a comment - a07855 , that's a much better approach for a variety of reasons. One recommended enhancement. Your task should download the agent jar when the task starts and then run the agent. This allows it to keep updated with new agent / remoting versions, at least when the task runs.

          Jesse Glick added a comment -

          Merged in Remoting; awaiting Remoting release, and integration of that into a weekly.

          Jesse Glick added a comment - Merged in Remoting; awaiting Remoting release, and integration of that into a weekly.

          Mark Waite added a comment -

          Remoting 4.12 release 7 Feb 2022. Pull request 6261 submitted by dependabot to include it in a future release of Jenkins core.

          Mark Waite added a comment - Remoting 4.12 release 7 Feb 2022. Pull request 6261 submitted by dependabot to include it in a future release of Jenkins core.

          Shelly Gez added a comment -

          Any ETA for the release with the fix of this issue?

          Shelly Gez added a comment - Any ETA for the release with the fix of this issue?

          Mark Waite added a comment - - edited

          Pull request 6261 is merged into the master branch that should be released tomorrow as 2.335. It is also included in the proposed backports to be included in the 2.332.1 LTS release March 9, 2022.

          Mark Waite added a comment - - edited Pull request 6261 is merged into the master branch that should be released tomorrow as 2.335. It is also included in the proposed backports to be included in the 2.332.1 LTS release March 9, 2022.

            jglick Jesse Glick
            testengineer Bilawal Ali
            Votes:
            2 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: