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

Jenkins Slaves do not connect after update from version 2.95 to version 2.99

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Duplicate
    • Component/s: core, remoting
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      After having installed Jenkins Version 2.99, none of my slaves did connect to the server anymore. Even a restart of the java script on the slave did not help.

      Workaround: Update Remoting on the agent side to 3.15

        Attachments

          Issue Links

            Activity

            Hide
            oleg_nenashev Oleg Nenashev added a comment - - edited

            OK, Docker... So far I can say the following:

            • Master runs on the 8082 port according to the bundle, but the web UI suggests the 10004 port. It is a whatever port mapping or external proxy, I'd guess
            • Agent fails to connect to TcpAgentListener port, the connection is refused. Probably it's just because the port is not exposed
            • TcpAgentListener runs with port set to 0. It means the it will be taking a random port every restart
            • Since you run the master in Docker, I am not sure how it is supposed to work. You would have to expose each port on the Docker host. I doubt you do that.

            Please check which port is exposed up for TcpAgentListener, and make sure the same port is configured in the security global config. Since you run in Docker, I would definitely recommend setting port flags so that the port won't be changeable from UI:

            -Djenkins.model.Jenkins.slaveAgentPort=${YOUR_EXPOSED_PORT} -Djenkins.model.Jenkins.slaveAgentPortEnforce=true
            

            Example for Docker

            "TCP agent listener port=0" id=86 (0x56) state=RUNNABLE cpu=0% (running in native)
                at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
                at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
                at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
                at hudson.TcpSlaveAgentListener.run(TcpSlaveAgentListener.java:157)
            
            Show
            oleg_nenashev Oleg Nenashev added a comment - - edited OK, Docker... So far I can say the following: Master runs on the 8082 port according to the bundle, but the web UI suggests the 10004 port. It is a whatever port mapping or external proxy, I'd guess Agent fails to connect to TcpAgentListener port, the connection is refused. Probably it's just because the port is not exposed TcpAgentListener runs with port set to 0 . It means the it will be taking a random port every restart Since you run the master in Docker, I am not sure how it is supposed to work. You would have to expose each port on the Docker host. I doubt you do that. Please check which port is exposed up for TcpAgentListener, and make sure the same port is configured in the security global config. Since you run in Docker, I would definitely recommend setting port flags so that the port won't be changeable from UI: -Djenkins.model.Jenkins.slaveAgentPort=${YOUR_EXPOSED_PORT} -Djenkins.model.Jenkins.slaveAgentPortEnforce=true Example for Docker "TCP agent listener port=0" id=86 (0x56) state=RUNNABLE cpu=0% (running in native) at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) at hudson.TcpSlaveAgentListener.run(TcpSlaveAgentListener.java:157)
            Hide
            blaoueille Bruno Laoueillé added a comment -

            Yes it's ok for that, moreover the configuration has not changed on that. We have put the 8081 port for Tcp agents with only JNLP/4 and it is accessible and configured on our Docker. (It was working well before updates).

            Show
            blaoueille Bruno Laoueillé added a comment - Yes it's ok for that, moreover the configuration has not changed on that. We have put the 8081 port for Tcp agents with only JNLP/4 and it is accessible and configured on our Docker. (It was working well before updates).
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Back to this story...

            > We have put the 8081 port

            How did you do that? The threaddump definitely suggests you're running with a random port

            Show
            oleg_nenashev Oleg Nenashev added a comment - Back to this story... > We have put the 8081 port How did you do that? The threaddump definitely suggests you're running with a random port
            Hide
            blaoueille Bruno Laoueillé added a comment -

            Hi,

            Sorry for late answer. But you are right, the configuration of the connection through tuneling was not set for the slave. I forgot it after my second installation (it was set only in the global security part).

            So after correcting this part the new version has worked perfectly.

            Thank you for your support.

            Regards,

            Bruno.

            Show
            blaoueille Bruno Laoueillé added a comment - Hi, Sorry for late answer. But you are right, the configuration of the connection through tuneling was not set for the slave. I forgot it after my second installation (it was set only in the global security part). So after correcting this part the new version has worked perfectly. Thank you for your support. Regards, Bruno.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Thanks for the reply! So this is not a defect. I will close it as a duplicate of JENKINS-48761, because the most of the voters/watchers followed the summary of the issue && timing was very coincidental

            Show
            oleg_nenashev Oleg Nenashev added a comment - Thanks for the reply! So this is not a defect. I will close it as a duplicate of JENKINS-48761 , because the most of the voters/watchers followed the summary of the issue && timing was very coincidental

              People

              • Assignee:
                oleg_nenashev Oleg Nenashev
                Reporter:
                michaelmotteler Michael M.
              • Votes:
                4 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: