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

Slaves with empty names destabilize Hudson operations

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • None
    • Platform: All, OS: All

      Hudson's "System Configuration" view allows to enter Slaves without names, and
      this easily screws the whole Hudson's, killing all the executors (they are
      marked in red as DEAD, and even changing the amount of executors configured.

      Afterwards, the Hudson needs to be restarted to restore its operations.

      There are some exceptions as well:

      1. After the slave with non name is added:

      Exception in thread "Executor #1 for " at
      hudson.model.Hudson.removeComputer(Hudson.java:294)
      at hudson.model.Computer.removeExecutor(Computer.java:166)
      at hudson.model.Executor.run(Executor.java:38)
      java.lang.NullPointerException
      at hudson.model.Queue$JobOffer.isNotExclusive(Queue.java:107)
      at hudson.model.Queue.choose(Queue.java:366)
      at hudson.model.Queue.pop(Queue.java:253)
      at hudson.model.Executor.run(Executor.java:44)

      2. When trying to delete a Slave without name.

      Exception in thread "Executor #2 for " java.lang.IllegalStateException: Trying
      to remove unknown computer: hudson.model.Computer@12cd8d4
      at hudson.model.Hudson.removeComputer(Hudson.java:294)
      at hudson.model.Computer.removeExecutor(Computer.java:166)
      at hudson.model.Executor.run(Executor.java:38)

          [JENKINS-150] Slaves with empty names destabilize Hudson operations

          Hmm. I added a new slave with empty name but with description, etc.
          I was able to add it without any error. I then created a new job, tied that to
          this no-name slave, and deleted the slave.

          All happened without any error.

          Perhaps the fix to 149 has some impact on this? Could you see if you can still
          cause the same problem? If so, can you post a bit more detailed instruction to
          reproduce the problem?

          Kohsuke Kawaguchi added a comment - Hmm. I added a new slave with empty name but with description, etc. I was able to add it without any error. I then created a new job, tied that to this no-name slave, and deleted the slave. All happened without any error. Perhaps the fix to 149 has some impact on this? Could you see if you can still cause the same problem? If so, can you post a bit more detailed instruction to reproduce the problem?

          vsizikov added a comment -

          With Hudson 1.59 and 1.60 the exception is similar to what described in ISSUE #149.

          With the current build (from todays workspace, 13 Nov 2006, that contains bugfix
          for ISSUE #149), I don't see exception mentioned in #149, but I see the
          exceptions mentioned earlier.

          For me, reproducing them is very simple:

          Configuration -> Add new slave, all fields EMPTY -> Click OK -> Configuration ->
          Delete a slave with all empty fields -> Exception:

          Exception in thread "Executor #4 for " java.lang.IllegalStateException: Trying
          to remove unknown computer: hudson.model.Computer@773d03
          at hudson.model.Hudson.removeComputer(Hudson.java:294)
          at hudson.model.Computer.removeExecutor(Computer.java:166)
          at hudson.model.Executor.run(Executor.java:38)

          I use mvn -o jetty:run to start Hudson.

          Should probably try with war properly deployed on Tomcat.

          vsizikov added a comment - With Hudson 1.59 and 1.60 the exception is similar to what described in ISSUE #149. With the current build (from todays workspace, 13 Nov 2006, that contains bugfix for ISSUE #149), I don't see exception mentioned in #149, but I see the exceptions mentioned earlier. For me, reproducing them is very simple: Configuration -> Add new slave, all fields EMPTY -> Click OK -> Configuration -> Delete a slave with all empty fields -> Exception: Exception in thread "Executor #4 for " java.lang.IllegalStateException: Trying to remove unknown computer: hudson.model.Computer@773d03 at hudson.model.Hudson.removeComputer(Hudson.java:294) at hudson.model.Computer.removeExecutor(Computer.java:166) at hudson.model.Executor.run(Executor.java:38) I use mvn -o jetty:run to start Hudson. Should probably try with war properly deployed on Tomcat.

          vsizikov added a comment -

          I tried with the latest stock version of Hudson 1.61, deployed on Tomcat, and
          can see the same problems - adding slaves with empty fields leads to problems in
          Hudson operations, like termination of executors, incorrect number of executors,
          and inability of Hudson to execute builds until it's restarted.

          If a slave with empty fields is configured to "utilize this slave as much as
          possible" then all the started tasks will fail with the following weird exception:

          Building remotely on
          ERROR: Failed to mkdirs: http://HOSTNAME:9080/hudson/job/PROJECT/ws/
          java.io.IOException: Failed to mkdirs:
          +http://HOSTNAME:9080/hudson/job/PROJECT/ws/
          at hudson.FilePath.mkdirs(FilePath.java:69)
          at hudson.model.Project.checkout(Project.java:290)
          at hudson.model.Build$1.run(Build.java:307)
          at hudson.model.Run.run(Run.java:512)
          at hudson.model.Build.run(Build.java:289)
          at hudson.model.Executor.run(Executor.java:60)

          If the slave with empty fields is configured with "leave this machine ..."
          then all the executors are eventually reported DEAD in read, an no builds can be
          done, and for some reason I see that most of my projects scheduled to run, even
          though there were no changes in repositories, and after Hudson restart they are
          executed.

          I guess my point is that slaves with empty fields cause so many various problems
          that they should be effectively disallowed or some defaults should be applied to
          the empty fields, like, for example, "UNNAMED SLAVE #1", etc.

          vsizikov added a comment - I tried with the latest stock version of Hudson 1.61, deployed on Tomcat, and can see the same problems - adding slaves with empty fields leads to problems in Hudson operations, like termination of executors, incorrect number of executors, and inability of Hudson to execute builds until it's restarted. If a slave with empty fields is configured to "utilize this slave as much as possible" then all the started tasks will fail with the following weird exception: Building remotely on ERROR: Failed to mkdirs: http://HOSTNAME:9080/hudson/job/PROJECT/ws/ java.io.IOException: Failed to mkdirs: + http://HOSTNAME:9080/hudson/job/PROJECT/ws/ at hudson.FilePath.mkdirs(FilePath.java:69) at hudson.model.Project.checkout(Project.java:290) at hudson.model.Build$1.run(Build.java:307) at hudson.model.Run.run(Run.java:512) at hudson.model.Build.run(Build.java:289) at hudson.model.Executor.run(Executor.java:60) If the slave with empty fields is configured with "leave this machine ..." then all the executors are eventually reported DEAD in read, an no builds can be done, and for some reason I see that most of my projects scheduled to run, even though there were no changes in repositories, and after Hudson restart they are executed. I guess my point is that slaves with empty fields cause so many various problems that they should be effectively disallowed or some defaults should be applied to the empty fields, like, for example, "UNNAMED SLAVE #1", etc.

          Added form error check.

          Kohsuke Kawaguchi added a comment - Added form error check.

            Unassigned Unassigned
            vsizikov vsizikov
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: