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

IOException during cleanup hides underlying failure when creating jobs via API

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • None
    • Jenkins 2.60.2, multiple plugins (list available if required), Windows Server 2012 R2, JRE 1.8u144 64-bit

      We're trying to find the most efficient way to migrate jobs from an old instance (1.593) onto a new instance (2.60.2). Currently trying the API to migrate the jobs by reading the config XML from the old server and POSTing it to the new server as described at https://stackoverflow.com/questions/9815273/how-to-get-a-list-of-installed-jenkins-plugins-with-name-and-version-pair. We've got all the authentication and crumb components of this working except during import, we get an exception on the new server:

      Caused by: java.io.IOException: Unable to delete 'D:\.jenkins\jobs\ServiceFramework_1.x-Checkmarx'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
      	at hudson.Util.deleteRecursive(Util.java:352)
      	at hudson.model.ItemGroupMixIn.createProjectFromXML(ItemGroupMixIn.java:305)
      	at hudson.model.ItemGroupMixIn.createTopLevelItem(ItemGroupMixIn.java:189)
      	at jenkins.model.Jenkins.doCreateItem(Jenkins.java:3841)
      	at java.lang.invoke.MethodHandle.invokeWithArguments(Unknown Source)
      	at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:343)
      	... 77 more
      Caused by: java.nio.file.FileSystemException: D:\.jenkins\jobs\ServiceFramework_1.x-Checkmarx\config.xml: The process cannot access the file because it is being used by another process.
      	at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
      	at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
      	at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
      	at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
      	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source)
      	at java.nio.file.Files.deleteIfExists(Unknown Source)
      	at hudson.Util.tryOnceDeleteFile(Util.java:290)
      	at hudson.Util.tryOnceDeleteRecursive(Util.java:370)
      	at hudson.Util.tryOnceDeleteContentsRecursive(Util.java:389)
      	at hudson.Util.tryOnceDeleteRecursive(Util.java:369)
      	at hudson.Util.deleteRecursive(Util.java:347)
      	... 82 more
      

      After looking at the ItemGroupMixIn, it appears that this exception is being thrown in the finally block which is cleaning up after something went wrong during the import:

      public synchronized TopLevelItem createProjectFromXML(String name, InputStream xml) throws IOException {
              ...
              try {
                  ...
              } catch (TransformerException e) {
                  success = false;
                  throw new IOException("Failed to persist config.xml", e);
              } catch (SAXException e) {
                  success = false;
                  throw new IOException("Failed to persist config.xml", e);
              } catch (IOException e) {
                  success = false;
                  throw e;
              } catch (RuntimeException e) {
                  success = false;
                  throw e;
              } finally {
                  if (!success) {
                      // if anything fails, delete the config file to avoid further confusion
                      Util.deleteRecursive(dir);
                  }
              }
          }
      

      However, since the exception is thrown in the finally block, we do not have any record of the original cause of the exception which resulted in the code in the finally block running. From the exception and the state of the files on disk, the import process still retained a lock on the 0KB config.xml file which could not be successfully imported. Best guess is that there is some problem parsing or transforming the incoming XML file but currently we cannot get any additional information.

      Suggestion is that the cleanup code requires a try-catch and if anything goes wrong, log that as a problem but then ensure that the original causal exception is captured so that the user can investigate further.

            Unassigned Unassigned
            stevenv Steven Visagie
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: