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

Wrong Permission of slave workspace

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      Sometimes the workspace directory on my linux slave has the wrong chmod set. The hudson ssh user has +r and +w permissions on the directory, but it's missing the +x permission, so the directory can't be entered. On first usage the directorys are ctreated with the correct permissions. Some undefined time later the ermissions go wrong. Deleting the directory makes hudson recreate it with the correct permissions, but they will go wrong again after a while.

      The error leads to the following stack trace:

      Started by user anonymous
      Building remotely on lisa-build.deu.hp.com
      java.io.IOException: Failed to mkdirs: /home/delta/hudson/workspace/lisa-review-single
      at hudson.FilePath.mkdirs(FilePath.java:812)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1080)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
      at hudson.model.Run.run(Run.java:1280)
      at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:293)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:140)

        Attachments

          Issue Links

            Activity

            Hide
            tony7682 Tony Panza added a comment -

            I am seeing this as well. I tried upgrading to the latest Subversion plugin, but that has not helped. I have also tried changing the checkout strategy to always check out a fresh copy (instead of 'svn update' as much as possible), but that has not helped either.

            The configuration where I am seeing this is the following: Jenkins master: Ubuntu 11.04, running Jenkins 1.436. I am seeing it on 2 different slaves for the same 3 jobs. Both slaves are running Ubuntu 10.04.3 LTS. There are 20 other jobs that do not exhibit this behavior, including jobs that use the same slaves as the problematic jobs.

            The problem I'm seeing is that the top level workspace directory permission gets changed to 644 or 666. When this happens, the build fails, and I cannot wipe out the workspace from the Jenkins web interface. I need to SSH into the slave, cd /home/jenkins/workspace, then sudo rm -rf <job_name>. Then if I manually kick off the build via web interface, it works fine. If I manually kick off two builds back to back, they both work fine.

            For whatever reason, the behavior coincides with nightly scheduled builds. Those fail everytime.

            The other strange data point is that these three problematic jobs were working like clockwork for months. Now every scheduled nightly build fails due to this directory permissions issue.

            This is a major problem in my opinion. How can we elevate this to get more attention?

            Show
            tony7682 Tony Panza added a comment - I am seeing this as well. I tried upgrading to the latest Subversion plugin, but that has not helped. I have also tried changing the checkout strategy to always check out a fresh copy (instead of 'svn update' as much as possible), but that has not helped either. The configuration where I am seeing this is the following: Jenkins master: Ubuntu 11.04, running Jenkins 1.436. I am seeing it on 2 different slaves for the same 3 jobs. Both slaves are running Ubuntu 10.04.3 LTS. There are 20 other jobs that do not exhibit this behavior, including jobs that use the same slaves as the problematic jobs. The problem I'm seeing is that the top level workspace directory permission gets changed to 644 or 666. When this happens, the build fails, and I cannot wipe out the workspace from the Jenkins web interface. I need to SSH into the slave, cd /home/jenkins/workspace, then sudo rm -rf <job_name>. Then if I manually kick off the build via web interface, it works fine. If I manually kick off two builds back to back, they both work fine. For whatever reason, the behavior coincides with nightly scheduled builds. Those fail everytime. The other strange data point is that these three problematic jobs were working like clockwork for months. Now every scheduled nightly build fails due to this directory permissions issue. This is a major problem in my opinion. How can we elevate this to get more attention?
            Hide
            tony7682 Tony Panza added a comment -

            I have sponsored a bounty for this issue on Freedom Sponsors: http://www.freedomsponsors.org/core/issue/307/wrong-permission-of-slave-workspace

            Show
            tony7682 Tony Panza added a comment - I have sponsored a bounty for this issue on Freedom Sponsors: http://www.freedomsponsors.org/core/issue/307/wrong-permission-of-slave-workspace
            Hide
            tony7682 Tony Panza added a comment -

            Possibly related to issue 16541: https://issues.jenkins-ci.org/browse/JENKINS-16451 (Workspace cleanup chmods the top-level directory to complete crap)

            Show
            tony7682 Tony Panza added a comment - Possibly related to issue 16541: https://issues.jenkins-ci.org/browse/JENKINS-16451 (Workspace cleanup chmods the top-level directory to complete crap)
            Hide
            scientist_st Samuel Stirtzel added a comment -

            JENKINS-16033 could be a duplicate of this Bug.

            Show
            scientist_st Samuel Stirtzel added a comment - JENKINS-16033 could be a duplicate of this Bug.
            Hide
            trejkaz trejkaz added a comment -

            I wish Jenkins could at least include the cause of the exception in this situation... we're seeing the same error, even though it seemingly successfully created the directory it's complaining about.

            Show
            trejkaz trejkaz added a comment - I wish Jenkins could at least include the cause of the exception in this situation... we're seeing the same error, even though it seemingly successfully created the directory it's complaining about.

              People

              • Assignee:
                Unassigned
                Reporter:
                tisoft_media tisoft_media
              • Votes:
                5 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated: