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

RPM post-install should not do a "chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}"

      The jenkins-1.565-1.1 RPM contains a post-install script with performs the following:

      # Ensure the right ownership on files
      . /etc/sysconfig/jenkins
      chown -R ${JENKINS_USER:-jenkins} /var/log/jenkins
      chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}
      

      These chowns can take a very long time on systems with lots of files. A couple of our Jenkins boxes have thousands of files in a the /var/lib/jenkins/workspace directory (which itself is a network mount), which means this chown takes many minutes to complete (like ~15 minutes) and actually changes the ownership of no files. This holds up package deployment unnecessarily.

      I propose that either these chowns be removed entirely (the RPM spec sets the ownership of things the RPM puts down), or better yet that they're restricted to specific files.

          [JENKINS-23273] RPM post-install should not do a "chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}"

          Ralph Bolton created issue -
          Ralph Bolton made changes -
          Description Original: The jenkins-1.565-1.1 RPM contains a post-install script with performs the following:

          # Ensure the right ownership on files
          . /etc/sysconfig/jenkins
          chown -R ${JENKINS_USER:-jenkins} /var/log/jenkins
          chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}

          These chowns can take a very long time on systems with lots of files. A couple of our Jenkins boxes have thousands of files in a the /var/lib/jenkins/workspace directory (which itself is a network mount), which means this chown takes many minutes to complete (like ~15 minutes). This holds up package deployment unnecessarily.

          I propose that either these chowns be removed entirely (the RPM spec sets the ownership of things the RPM puts down), or better yet that they're restricted to specific files.

          New: The jenkins-1.565-1.1 RPM contains a post-install script with performs the following:
          {quote}{noformat}
          # Ensure the right ownership on files
          . /etc/sysconfig/jenkins
          chown -R ${JENKINS_USER:-jenkins} /var/log/jenkins
          chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}
          {noformat}{quote}
          These chowns can take a very long time on systems with lots of files. A couple of our Jenkins boxes have thousands of files in a the /var/lib/jenkins/workspace directory (which itself is a network mount), which means this chown takes many minutes to complete (like ~15 minutes) and actually changes the ownership of no files. This holds up package deployment unnecessarily.

          I propose that either these chowns be removed entirely (the RPM spec sets the ownership of things the RPM puts down), or better yet that they're restricted to specific files.

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - Introduced by https://github.com/jenkinsci/jenkins/commit/4335bd435f9e5258831c5631bfab2fd837fd7719
          Oleg Nenashev made changes -
          Assignee New: Nicolas De Loof [ ndeloof ]

          This isn't just a performance problem. We have the workspace owned by a different group and this rpm tries to undo that.

          Chris Burroughs added a comment - This isn't just a performance problem. We have the workspace owned by a different group and this rpm tries to undo that.

          Daniel Beck added a comment -

          FYI this doesn't do what the issue title suggests. It makes the value of JENKINS_USER (loaded from /etc/sysconfig/jenkins) the owner, or jenkins if the variable is undefined.

          It also does not attempt to set the group.

          It'd probably be safe if you defined the JENKINS_USER env variable for RPM to use.

          Still, the performance issue remains. JENKINS-12231 probably just needs to be solved non-recursively (and needs to include /var/cache/jenkins)

          Daniel Beck added a comment - FYI this doesn't do what the issue title suggests. It makes the value of JENKINS_USER (loaded from /etc/sysconfig/jenkins) the owner, or jenkins if the variable is undefined. It also does not attempt to set the group. It'd probably be safe if you defined the JENKINS_USER env variable for RPM to use. Still, the performance issue remains. JENKINS-12231 probably just needs to be solved non-recursively (and needs to include /var/cache/jenkins)
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-12231 [ JENKINS-12231 ]
          Ralph Bolton made changes -
          Summary Original: RPM post-install should not do a "chown -R jenkins:jenkins /var/lib/jenkins" New: RPM post-install should not do a "chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}"

          Ralph Bolton added a comment -

          sorry, my mistake. You're right, it doesn't affect group. I wasn't aware of previous issues with running Jenkins as users other than 'jenkins', and so was imprecise in my description. I've edited to correct.

          Ralph Bolton added a comment - sorry, my mistake. You're right, it doesn't affect group. I wasn't aware of previous issues with running Jenkins as users other than 'jenkins', and so was imprecise in my description. I've edited to correct.

          Daniel Beck added a comment -

          Also, my comment was partially incorrect as well: As it'll load /etc/sysconfig/jenkins (unless you messed with the overall format of the file or specify a custom user somewhere else, in which case it's your own fault), it'll do the right thing.

          HOWEVER, it'll chown recursively when it doesn't need to. I expect the entire problem to vanish when the -R is removed.

          Daniel Beck added a comment - Also, my comment was partially incorrect as well: As it'll load /etc/sysconfig/jenkins (unless you messed with the overall format of the file or specify a custom user somewhere else, in which case it's your own fault), it'll do the right thing. HOWEVER, it'll chown recursively when it doesn't need to. I expect the entire problem to vanish when the -R is removed.

            rarabaolaza Raul Arabaolaza
            coofercat Ralph Bolton
            Votes:
            13 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated:
              Resolved: