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

server becomes unresponsive after encountering multiple symbolic link loops in a workspace

XMLWordPrintable

      after upgrading from 2.341 jenkins no longer seems to be able to handle something in my jobs when a symbolic link loop is in the workspace (as simple as ln -s .. loop in multiple subdirectories, in the example below {{{}dir1/source, dir2/source, etc.)}}
       

      I first thought it was a duplicate of JENKINS-40421 as I first encountered this on a project that tried to archive the directory with that symbolic link loop, but I've just encountered it now on an unrelated project which is not archiving it, and just realized the key that is there are multiple directories with back links as illustrated by log below.

       

      The only hint that there is a problem is a lot of messages such as the one below with various variations of the dir names:

      Sep 12 09:16:21 hostname jenkins[11436]: skipping symbolic link /var/lib/jenkins/jobs/jobname/workspace/dir1/source/dir2/source/dir1/source/dir3/source/dir2/source/dir1/source -- too many levels of symbolic links.
       

      The behaviour observed is that it starts with a dozen of such lines per second, then slows down to a crawl and I start seeing OOM error messages with threads being killed, and jenkins becomes unresponsive.

       

      I unfortunately was not able to pinpoint what is crawling the workspace at that point – I'm pretty sure one of the first times I saw it was file existence check when modifying the artifact patterns with a double-wildcard, but there must be others as there was no such wildcard in the second case (and I wasn't editing the artifact list anyway.. although configuration page was open so I could have selected the field at some point if that is enough to trigger a walk...)

       

      Jenkins should not just detect a loop when path becomes too long (error happens to be 64 directories deep all the times so I assume that's the limit), but instead either not follow symlinks at all in wildcard cases, or detect that the symlink destination is within a directory it already considered.

       

      I've had this happen with just 3 directories (3 build variants with a single .. symlink), but if we do a full walk assuming a starting depth of 8 to 64 (leaving 56), picking one in three every two paths, we get 3^28 = 22T possibilities. No wonder jenkins goes OOM with that.

       

      Happy to try to reproduce in a test setup if you think one of our plugin does it, but I believe it should at last happen with the archival preview – just setup such a workspace with a few backlinks, go back to configuration screen and try to add a file for archival.

       

      I'm also certain we never got this crash on jenkins 2.341, but I haven't been modifying the projects that exhibit this behaviour for much longer so it's possible it was present and the bug has been introduced before that; I don't have time to bisect it right now but I'm not sure that'd be very useful anyway.

       

      Thanks,

      Dominique Martinet

            Unassigned Unassigned
            martinetd Dominique Martinet
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: