• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • other, versionnumber-plugin
    • None
    • tomcat 7.0.22
      windows server 2008 r2

      Jenkins version 1.437

      If I stop the Apache Tomcat windows service, a bunch of my builds disappear from the history of the jobs. The missing builds are still on disk in the build folder, it just doesn't "find" them when making the history list.

      The jobs that lose history use the version number plugin and I had recently changed the version format from "4.3.${BUILDS_ALL_TIME}" to "4.4.${BUILDS_ALL_TIME}". The builds that disappear are all those after I changed this format. Also affects jobs that are downstream from those with version number changes.

      I could not find any Component related to the build history for a job. If someone knows what that should be feel free to change this. Also, sorry if there's not enough (or to much) information, this is the first Jenkins bug I have filed.

          [JENKINS-11938] Jenkins loses builds when restarted

          Dorin Marinca added a comment - - edited

          +1 Same issue on winxp_sp3 jenkins 1.452 (but seen several times in older versions). using setenv 1.1 and not using envinject.
          The builds don't reappear on "Reload Configuration from Disk". Could somebody suggest how could I force this reload differently?
          It's critical in my context as we users download often latest successful artifacts from jenkins.

          It seems that the jobs where this issue are parametrized with load file.

          FYI (I don't know if it's related but) in jenkins.err.log file I have a lots of exceptions like this on various upload*.tmp files:
          ---- Debugging information ----
          message : Could not call org.apache.commons.fileupload.disk.DiskFileItem.readObject()
          cause-exception : java.io.FileNotFoundException
          cause-message : C:\DOCUME~1\dmarinca\LOCALS~1\Temp\upload_4065e0d0_1351ff4c1c6_8000_00000013.tmp (The system cannot find the file specified)
          class : hudson.model.FreeStyleBuild
          required-type : org.apache.commons.fileupload.disk.DiskFileItem
          path : /build/actions/hudson.model.ParametersAction/parameters/hudson.model.FileParameterValue/file/org.apache.commons.fileupload.disk.DiskFileItem
          line number : 19
          -------------------------------

          could be interpreted this as:
          parametrized builds loose somehow some of their hidden data files (e.g. uploaded files used during builds) and thus they cannot be shown by jenkins in history?

          Dorin Marinca added a comment - - edited +1 Same issue on winxp_sp3 jenkins 1.452 (but seen several times in older versions). using setenv 1.1 and not using envinject. The builds don't reappear on "Reload Configuration from Disk". Could somebody suggest how could I force this reload differently? It's critical in my context as we users download often latest successful artifacts from jenkins. It seems that the jobs where this issue are parametrized with load file. FYI (I don't know if it's related but) in jenkins.err.log file I have a lots of exceptions like this on various upload*.tmp files: ---- Debugging information ---- message : Could not call org.apache.commons.fileupload.disk.DiskFileItem.readObject() cause-exception : java.io.FileNotFoundException cause-message : C:\DOCUME~1\dmarinca\LOCALS~1\Temp\upload_ 4065e0d0_1351ff4c1c6 _8000_00000013.tmp (The system cannot find the file specified) class : hudson.model.FreeStyleBuild required-type : org.apache.commons.fileupload.disk.DiskFileItem path : /build/actions/hudson.model.ParametersAction/parameters/hudson.model.FileParameterValue/file/org.apache.commons.fileupload.disk.DiskFileItem line number : 19 ------------------------------- could be interpreted this as: parametrized builds loose somehow some of their hidden data files (e.g. uploaded files used during builds) and thus they cannot be shown by jenkins in history?

          Mehul Sanghvi added a comment -

          This is from an email I sent out to the Jenkins mailing list
          dated 2011-06-24. Unfortunately as I no longer work at the
          place, I am unable to provide further information about what
          version of Jenkins it was, etc. I thought it would be good
          to have this captured here in case it helps out in testing
          or following the code path.

          ------ begin email ------
          I had the following three Jobs in Jenkins:

          mehul-nightly
          BRANCH_5_X
          BRANCH_5_X-nightly

          mehul-nightly was the one I was actively working on. Once I got it
          configured and working the way I wanted it to work,
          I did the following:

          • deleted BRANCH_5_X-nightly
          • renamed mehul-nightly to BRANCH_5_X-nightly

          I went to bed around 1:30am having checked the log for build #258
          which was a success.
          This morning when the BRANCH_5_X-nightly ran at 2am, it got an
          unstable status (not an issue), but I no longer see
          any logs for the previous 258 builds! I looked on the Jenkins servers
          and there are no log files
          for any of the builds.

          Does anyone have pointers on what could have gone wrong or happened ?

          ----------- end of email --------

          Mehul Sanghvi added a comment - This is from an email I sent out to the Jenkins mailing list dated 2011-06-24. Unfortunately as I no longer work at the place, I am unable to provide further information about what version of Jenkins it was, etc. I thought it would be good to have this captured here in case it helps out in testing or following the code path. ------ begin email ------ I had the following three Jobs in Jenkins: mehul-nightly BRANCH_5_X BRANCH_5_X-nightly mehul-nightly was the one I was actively working on. Once I got it configured and working the way I wanted it to work, I did the following: deleted BRANCH_5_X-nightly renamed mehul-nightly to BRANCH_5_X-nightly I went to bed around 1:30am having checked the log for build #258 which was a success. This morning when the BRANCH_5_X-nightly ran at 2am, it got an unstable status (not an issue), but I no longer see any logs for the previous 258 builds! I looked on the Jenkins servers and there are no log files for any of the builds. Does anyone have pointers on what could have gone wrong or happened ? ----------- end of email --------

          Asher Aber added a comment - - edited

          I found a workaround for this issue.

          Use the following one liner in a script to create the /tmp/upload_...777.tmp files listed in the build.xml file:
          $ for file in `grep dfosFile build.xml |cut -d\> -f2|cut -d\< -f1`; do touch $file; done

          Hope this helps until a better fix is found.

          Another note to clarify the issue:
          The problem is that the uploaded parameter temp files that are created in /tmp are lost or deleted for old builds.
          As a result Jenkins throws an exception while reading the old build's XML files(build.xml).
          The end result is that old builds are not displayed.

          The above workaround parses the XML files and creates dummy files in /tmp.
          Once the /tmp files are in place Jenkins can successfully read the XML files and show the old builds.

          Asher Aber added a comment - - edited I found a workaround for this issue. Use the following one liner in a script to create the /tmp/upload_...777.tmp files listed in the build.xml file: $ for file in `grep dfosFile build.xml |cut -d\> -f2|cut -d\< -f1`; do touch $file; done Hope this helps until a better fix is found. Another note to clarify the issue: The problem is that the uploaded parameter temp files that are created in /tmp are lost or deleted for old builds. As a result Jenkins throws an exception while reading the old build's XML files(build.xml). The end result is that old builds are not displayed. The above workaround parses the XML files and creates dummy files in /tmp. Once the /tmp files are in place Jenkins can successfully read the XML files and show the old builds.

          Dorin Marinca added a comment -

          In fact the file pointed by <dfosFile> in build.xml files is saved (not lost) in <jenkins>\jobs\<job_name>\builds\<timestamp>\fileParameters\<here>. So there should be an issue on selection of value stored in <dfosFile>. Instead storing some temp file (that someone would remove for freeing the temp), jenkins should store the path to the file stored anyway under the build directory.

          Dorin Marinca added a comment - In fact the file pointed by <dfosFile> in build.xml files is saved (not lost) in <jenkins>\jobs\<job_name>\builds\<timestamp>\fileParameters\< here >. So there should be an issue on selection of value stored in <dfosFile>. Instead storing some temp file (that someone would remove for freeing the temp), jenkins should store the path to the file stored anyway under the build directory.

          Asher Aber added a comment -

          That is correct!

          The build.xml should not have the this type of reference:
          <dfosFile>/tmp/upload_1efd5df3_13659557023_8000_00000056.tmp</dfosFile>

          It should be:
          <dfosFile>/var/lib/jenkins/jobs/My_Project/builds/12/fileParameters/uploadedFile</dfosFile>

          The question is who can correct this?

          Asher Aber added a comment - That is correct! The build.xml should not have the this type of reference: <dfosFile>/tmp/upload_ 1efd5df3_13659557023 _8000_00000056.tmp</dfosFile> It should be: <dfosFile>/var/lib/jenkins/jobs/My_Project/builds/12/fileParameters/uploadedFile</dfosFile> The question is who can correct this?

          Hi,

          I have exactly the same problem. My workaround for this is to run this script before Jenkins start:
          path=/var/lib/jenkins/jobs
          `find $path -name build.xml -print0 | xargs -0 sed -i '/<file class="org.apache.commons.fileupload.disk.DiskFileItem" serialization="custom">/,/<\/file>/d'`

          but this is only workaround ... I have created a bug report for this:
          https://issues.jenkins-ci.org/browse/JENKINS-13536

          Blazej Mirowski added a comment - Hi, I have exactly the same problem. My workaround for this is to run this script before Jenkins start: path=/var/lib/jenkins/jobs `find $path -name build.xml -print0 | xargs -0 sed -i '/<file class="org.apache.commons.fileupload.disk.DiskFileItem" serialization="custom">/,/<\/file>/d'` but this is only workaround ... I have created a bug report for this: https://issues.jenkins-ci.org/browse/JENKINS-13536

          I had the same issue. For me, it was the Naginator plug-in, which threw NPEs after non-naginated builds (JENKINS-13791). They fixed it in 1.7, and now my build.xml files are successfully written again, and builds no longer disappear.

          Johannes Spohr added a comment - I had the same issue. For me, it was the Naginator plug-in, which threw NPEs after non-naginated builds ( JENKINS-13791 ). They fixed it in 1.7, and now my build.xml files are successfully written again, and builds no longer disappear.

          Jesse Glick added a comment -

          At least some of the comments here indicate it is a duplicate of JENKINS-13536, but probably some users commenting here have encountered unrelated bugs. Probably this needs to be closed as it has become too confused to follow and some reports lack sufficient detail.

          Jesse Glick added a comment - At least some of the comments here indicate it is a duplicate of JENKINS-13536 , but probably some users commenting here have encountered unrelated bugs. Probably this needs to be closed as it has become too confused to follow and some reports lack sufficient detail.

          Ben Dean added a comment -

          I believe this issue is fixed. In recent releases of Jenkins (1.528, likely others), restarting Jenkins does not cause jobs to lose their builds.

          Ben Dean added a comment - I believe this issue is fixed. In recent releases of Jenkins (1.528, likely others), restarting Jenkins does not cause jobs to lose their builds.

          Ben Dean added a comment -

          closing issue as this is pretty old and I'm pretty sure it's fixed and even if it's not, it should be logged as a new issue with better details. This one is too confusing to deal with even if it were still a problem (which I do not believe it is).

          Ben Dean added a comment - closing issue as this is pretty old and I'm pretty sure it's fixed and even if it's not, it should be logged as a new issue with better details. This one is too confusing to deal with even if it were still a problem (which I do not believe it is).

            Unassigned Unassigned
            b_dean Ben Dean
            Votes:
            26 Vote for this issue
            Watchers:
            32 Start watching this issue

              Created:
              Updated:
              Resolved: