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

softlinks in build for lastSuccessful and lastStable failing

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Critical
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
    • Environment:
      ubuntu 1604 VM
      docker jenkins 2.101
    • Similar Issues:

      Description

      When running a simple job (perl script) which gets a dump from remote database directly to workspace and fills another remote database the console output shows the stack trace:

      ln builds/lastSuccessfulBuild /var/jenkins_home/jobs/Redmine3-DB-Copy/lastSuccessful failed
      java.nio.file.DirectoryNotEmptyException: /var/jenkins_home/jobs/Redmine3-DB-Copy/lastSuccessful
          at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
          at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
          at java.nio.file.Files.deleteIfExists(Files.java:1165)
          at hudson.Util.createSymlink(Util.java:1321)
          at hudson.model.Run.createSymlink(Run.java:1866)
          at hudson.model.Run.updateSymlinks(Run.java:1847)
          at hudson.model.Run.execute(Run.java:1725)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:97)
          at hudson.model.Executor.run(Executor.java:429)
      ln builds/lastStableBuild /var/jenkins_home/jobs/Redmine3-DB-Copy/lastStable failed
      java.nio.file.DirectoryNotEmptyException: /var/jenkins_home/jobs/Redmine3-DB-Copy/lastStable
          at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
          at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
          at java.nio.file.Files.deleteIfExists(Files.java:1165)
          at hudson.Util.createSymlink(Util.java:1321)
          at hudson.model.Run.createSymlink(Run.java:1866)
          at hudson.model.Run.updateSymlinks(Run.java:1848)
          at hudson.model.Run.execute(Run.java:1725)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:97)
          at hudson.model.Executor.run(Executor.java:429)
      [EnvInject] - Loading node environment variables.
      

       

        Attachments

          Activity

          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Sounds like a core bug.
          CC Devin Nusbaum who was working on the symlinks in Jenkins recently

          Show
          oleg_nenashev Oleg Nenashev added a comment - Sounds like a core bug. CC Devin Nusbaum who was working on the symlinks in Jenkins recently
          Hide
          dnusbaum Devin Nusbaum added a comment - - edited

          This sounds like a duplicate of JENKINS-21330 (I do not think it is related to my recent changes). My guess is that /var/jenkins_home/jobs/Redmine3-DB-Copy/lastSuccessful and /var/jenkins_home/jobs/Redmine3-DB-Copy/lastStable are actual directories instead of symlinks (maybe because of a faulty backup/restore that converted the symlinks into directories).

          A workaround would be to delete those directories manually so that the next build can create the symlinks correctly.

          We could prevent the issue by using `Util.deleteRecursive` instead of `File.deleteIfExists` here, but maybe that is too risky in case someone cares about the contents of the directory.

          Show
          dnusbaum Devin Nusbaum added a comment - - edited This sounds like a duplicate of JENKINS-21330  (I do not think it is related to my recent changes). My guess is that /var/jenkins_home/jobs/Redmine3-DB-Copy/lastSuccessful and /var/jenkins_home/jobs/Redmine3-DB-Copy/lastStable are actual directories instead of symlinks (maybe because of a faulty backup/restore that converted the symlinks into directories). A workaround would be to delete those directories manually so that the next build can create the symlinks correctly. We could prevent the issue by using `Util.deleteRecursive` instead of `File.deleteIfExists` here , but maybe that is too risky in case someone cares about the contents of the directory.

            People

            • Assignee:
              Unassigned
              Reporter:
              trstn Torsten Sprich
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: