• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • plugin-proposals
    • None
    • OS is SLES9 running Apache Tomcat 6.0.18 / JDK 5 / Hudson 1.339 war deployed to Tomcat server

      When using the Manage Plugins page from the Manage Hudson console, an issue exists where you can pass the connectivity check OK (making sure you have the IP mapped in /etc/hosts to the plugin location) - but then the plug-in you've either selected for update or new install just sits in Pending status. Just below the connection Success message...One gets the grey ball icon w/ the plugin name and it just sits in "Pending" status....and never goes any further. There is the button to click and restart Hudson once it is done...but the grey ball icon never goes green (I use the green ball plugin btw, so normally it goes green when ready).

      This happens whether updating existing or adding new plugins. Consequently, I have had to go to the manual process, copying the *.hpi files into the /plugins folder under the HUDSON_HOME and doing start/stop of Hudson from the Tomcat Manager console.

      According to the users@hudson.dev.java.net mailing list, this is a known issue as taken from the response today from another user:

      -----------------------------------------------------------------------

      Jesse Farinacci <jieryn@gmail.com>
      reply-to users@hudson.dev.java.net
      to users@hudson.dev.java.net
      date Tue, Jan 19, 2010 at 10:42 AM
      subject Re: Plug-ins question - plug-in install/update stuck in "Pending" ?
      unsubscribe Unsubscribe from this sender

      hide details 10:42 AM (11 hours ago)

      Hi,

      On Tue, Jan 19, 2010 at 10:28 AM, Mark Streit <mcs130@gmail.com> wrote:
      > So this is a known issue then with Hudson? If so, has this been reported as
      > a problem yet? Interesting that you say this because it seems when the
      > plug-in location changed to http://jenkins-ci.org ( I had to add a new entry
      > in /etc/hosts ) .... it started to show up. The connectivity checks all
      > come back "Success". The plug-in ball icon just sits Grey and in a pending
      > state forever.
      >

      Yep, this is exactly what I see happening. The network connectivity
      check returns success (perhaps this is the actual bug) but the
      download of the plugin doesn't actually ever seem to complete. I can't
      say 'forever' because I usually give up watching it after about 5 or
      10 minutes. I can directly fetch the plugins with curl, from the
      Hudson server instance, logged in as the user that Hudson runs under,
      so I don't think there's actually a real connectivity problem. Perhaps
      Hudson is doing some sort of slick underhanded UDP, or custom
      protocol, thing to fetch plugins which is being blocked by our
      corporate infrastructure?

      It's not really something I care about as I already have scripts which
      invoke Maven to deploy the file via scp to where Hudson can see it. I
      find this works best for our environment as I can run my own tests
      beforehand inside the Hudson project itself.

      Anyway, feel free to report it, I will happily subscribe to it.

          [JENKINS-5319] plug-in install/update stuck in "Pending"

          Alan Harder added a comment -

          I don't think this is related, but do note that JENKINS-3662 was just fixed in 1.341. But this was just for upgrading bundled plugins, so this is another problem since you're seeing it for other plugins.

          Alan Harder added a comment - I don't think this is related, but do note that JENKINS-3662 was just fixed in 1.341. But this was just for upgrading bundled plugins, so this is another problem since you're seeing it for other plugins.

          Alan Harder added a comment -

          however, I also improved the error reporting with that change in 1.341, so can you try with that Hudson release and see if you get anything in your Hudson/webserver log? Also check for javascript errors in your browser. thanks.

          Alan Harder added a comment - however, I also improved the error reporting with that change in 1.341, so can you try with that Hudson release and see if you get anything in your Hudson/webserver log? Also check for javascript errors in your browser. thanks.

          Arnaud Héritier added a comment - - edited

          Same thing for me for a long time now. I just upgraded to 1.142
          No I have an error :

          SEVERE: Failed to install Subversion Plugin
          java.lang.NullPointerException
          	at hudson.security.ContainerAuthentication.getPrincipal(ContainerAuthentication.java:79)
          	at hudson.security.ContainerAuthentication.getName(ContainerAuthentication.java:91)
          	at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:699)
          	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
          	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
          	at java.lang.Thread.run(Thread.java:619)
          

          My env : tomcat 6.0.16 + LDAP (as Delegate to servlet container - configured in tomcat)

          Arnaud Héritier added a comment - - edited Same thing for me for a long time now. I just upgraded to 1.142 No I have an error : SEVERE: Failed to install Subversion Plugin java.lang.NullPointerException at hudson.security.ContainerAuthentication.getPrincipal(ContainerAuthentication.java:79) at hudson.security.ContainerAuthentication.getName(ContainerAuthentication.java:91) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:699) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang. Thread .run( Thread .java:619) My env : tomcat 6.0.16 + LDAP (as Delegate to servlet container - configured in tomcat)

          Alan Harder added a comment -

          wow, I have no idea how you could hit that.
          The line getting NPE is:

          return request.getUserPrincipal().getName();
          

          and this is in a ContainerAuthentication object that was created like this:

          if(req.getUserPrincipal()!=null)
                          SecurityContextHolder.getContext().setAuthentication(new ContainerAuthentication(req));
          

          ie, it checked to make sure getUserPrincipal is not null before creating the object.. !?

          Alan Harder added a comment - wow, I have no idea how you could hit that. The line getting NPE is: return request.getUserPrincipal().getName(); and this is in a ContainerAuthentication object that was created like this: if (req.getUserPrincipal()!= null ) SecurityContextHolder.getContext().setAuthentication( new ContainerAuthentication(req)); ie, it checked to make sure getUserPrincipal is not null before creating the object.. !?

          Alan Harder added a comment -

          ok, I have a theory at least.. it's taking the request object from when you clicked the "install" button, but that request completes and the install is actually a background process. Even though we held onto that request object, perhaps the authenticated user in that object was cleared out by tomcat when the request was completed.

          Alan Harder added a comment - ok, I have a theory at least.. it's taking the request object from when you clicked the "install" button, but that request completes and the install is actually a background process. Even though we held onto that request object, perhaps the authenticated user in that object was cleared out by tomcat when the request was completed.

          I tried to upgrade from tomcat 6.0.16 to 6.0.24 because there are some fix about NPE in JNDI connector but it wasn't related

          Arnaud Héritier added a comment - I tried to upgrade from tomcat 6.0.16 to 6.0.24 because there are some fix about NPE in JNDI connector but it wasn't related

          Alan Harder added a comment -

          aheritier, your case is JENKINS-5382 which was just fixed for 1.343.

          mcs130, do you also delegate authentication to tomcat?

          Alan Harder added a comment - aheritier, your case is JENKINS-5382 which was just fixed for 1.343. mcs130, do you also delegate authentication to tomcat?

          Cool thx mindless and kohsuke. I hope you'll release it soon.

          Arnaud Héritier added a comment - Cool thx mindless and kohsuke. I hope you'll release it soon.

          Alan Harder added a comment -

          Assuming this is the same as JENKINS-5382, and closing.
          If your case is different and you still see "pending" on a recent Hudson release (other than 1.344.. this release has a new bug that will be fixed in 1.345), let us know..

          Alan Harder added a comment - Assuming this is the same as JENKINS-5382 , and closing. If your case is different and you still see "pending" on a recent Hudson release (other than 1.344.. this release has a new bug that will be fixed in 1.345), let us know..

          For me it is fixed. Thx a lot.

          Arnaud Héritier added a comment - For me it is fixed. Thx a lot.

            Unassigned Unassigned
            mcs130 mcs130
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: