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

Workspace cleanup chmods the top-level directory to complete crap

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Duplicate
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      Started by upstream project "test_mp" build number 113
      originally caused by:
      Started by user Yury Pukhalsky
      Building remotely on hpit in workspace /build/hudson/workspace/test_mp/label/hpit

      Deleting project workspace... done

      Checking out a fresh workspace because /build/hudson/workspace/test_mp/label/hpit/autotest doesn't exist
      Cleaning local Directory autotest
      Checking out svn+ssh://svn@svn/SV_RND/trunk/SVFE/testing/autotest at revision '2013-01-23T13:31:04.219 +0400'
      ERROR: Failed to check out svn+ssh://svn@svn/SV_RND/trunk/SVFE/testing/autotest
      org.tmatesoft.svn.core.SVNException: svn: E204899: Cannot create new file '/build/hudson/workspace/test_mp/label/hpit/autotest/.svn/lock': Permission denied (errno:13)

      And indeed, the permissions on label/hpit are changed to 666 whereas the permissions on label/ are intact.
      Happens only on HP-UX among our platforms.

        Attachments

          Issue Links

            Activity

            Hide
            vjuranek vjuranek added a comment -

            This is not an issue of ws cleanup plugin, but rather in Jenkins core as it uses Jenkins core functionality or deleting workspaces. It's usually caused by a file, which cannot be deteled (e.g. still open by another process). In such cases Jenkins tries to chmod upper directory (i.e. it's a feature, not a bug), which sometimes (especially on Unix) results into what you described. Moving into the "core" component.

            Show
            vjuranek vjuranek added a comment - This is not an issue of ws cleanup plugin, but rather in Jenkins core as it uses Jenkins core functionality or deleting workspaces. It's usually caused by a file, which cannot be deteled (e.g. still open by another process). In such cases Jenkins tries to chmod upper directory (i.e. it's a feature, not a bug ), which sometimes (especially on Unix) results into what you described. Moving into the "core" component.
            Hide
            aikipooh Yury Pukhalsky added a comment -

            Aha, ok.
            I think there are such files, alright. But yet it's very harsh behaviour — render the thing unusable
            Sometimes i even have workspace/ directory getting the Number of the Beast (albeit i haven't yet pinpointed it) and that is much worse.

            PS. As you seem to be alive, the 14875 is core bug too?

            Show
            aikipooh Yury Pukhalsky added a comment - Aha, ok. I think there are such files, alright. But yet it's very harsh behaviour — render the thing unusable Sometimes i even have workspace/ directory getting the Number of the Beast (albeit i haven't yet pinpointed it) and that is much worse. PS. As you seem to be alive, the 14875 is core bug too?
            Hide
            vjuranek vjuranek added a comment -

            yes, definitely agree that it's a bug, "a feature, not a bug" was a kind of (probably inappropriate) joke

            Show
            vjuranek vjuranek added a comment - yes, definitely agree that it's a bug, "a feature, not a bug" was a kind of (probably inappropriate) joke
            Hide
            tony7682 Tony Panza added a comment -

            Might this be related to issue 7823? https://issues.jenkins-ci.org/browse/JENKINS-7823 (Wrong Permission of slave workspace)

            Show
            tony7682 Tony Panza added a comment - Might this be related to issue 7823? https://issues.jenkins-ci.org/browse/JENKINS-7823 (Wrong Permission of slave workspace)
            Hide
            danielbeck Daniel Beck added a comment -

            vjuranek: I just checked the core sources but other than trying to make file + its parent writable if the first deletion attempt failed, I can't find it messing with permissions. Could you point me to the responsible code?

            Show
            danielbeck Daniel Beck added a comment - vjuranek : I just checked the core sources but other than trying to make file + its parent writable if the first deletion attempt failed, I can't find it messing with permissions. Could you point me to the responsible code?
            Hide
            danielbeck Daniel Beck added a comment -

            Another option would be that SCM's processWorkspaceBeforeDeletion(...) breaks things. What SCMs (Subversion, Git, Mercurial, ...) are used on the affected jobs? Does it also affect jobs that don't use any SCM?

            What workspace listeners are in use when this occurs? Run WorkspaceListener.all() in Manage Jenkins » Script Console and report the output.

            Re Workspace Cleanup plugin, maybe this should be changed to report failure to delete in one of the tries at least to the system log:
            https://github.com/jenkinsci/ws-cleanup-plugin/blob/267f3/src/main/java/hudson/plugins/ws_cleanup/PreBuildCleanup.java#L103

            Show
            danielbeck Daniel Beck added a comment - Another option would be that SCM's processWorkspaceBeforeDeletion(...) breaks things. What SCMs (Subversion, Git, Mercurial, ...) are used on the affected jobs? Does it also affect jobs that don't use any SCM? What workspace listeners are in use when this occurs? Run WorkspaceListener.all() in Manage Jenkins » Script Console and report the output. Re Workspace Cleanup plugin, maybe this should be changed to report failure to delete in one of the tries at least to the system log: https://github.com/jenkinsci/ws-cleanup-plugin/blob/267f3/src/main/java/hudson/plugins/ws_cleanup/PreBuildCleanup.java#L103
            Hide
            danielbeck Daniel Beck added a comment -

            This duplicates JENKINS-16033, so resolving as such. I've posted instructions there that may help investigate the cause, so if you're affected by this issue, please go there and take a look.

            Show
            danielbeck Daniel Beck added a comment - This duplicates JENKINS-16033 , so resolving as such. I've posted instructions there that may help investigate the cause, so if you're affected by this issue, please go there and take a look.

              People

              • Assignee:
                lvotypkova Lucie Votypkova
                Reporter:
                aikipooh Yury Pukhalsky
              • Votes:
                1 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: