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

RPM upgrade does not honor JENKINS_USER, and always resets files ownership to "jenkins"

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • core
    • None
    • Linux, CentOS and Fedora. Using RPM installation and upgrade

    Description

      I have a Jenkins installation for which I changed the "JENKINS_USER" and "JENKINS_HOME" (in /etc/sysconfig/jenkins) from the defaults.
      When I do an upgrade via yum/RPM, it sets the ownership of /var/log/jenkins back to default user "jenkins" (instead of honoring my JENKINS_USER configuration).

      This prevents Jenkins from starting after an upgrade. And since it cannot write to the log file, it may not be easy to figure out what went wrong.

      Attachments

        Issue Links

          Activity

            Simple patch that solves the problem. Not ideal, since the %files section is also setting the ownership (hardcoded to 'jenkins'), but works for me.

            fernando Fernando Dobladez added a comment - Simple patch that solves the problem. Not ideal, since the %files section is also setting the ownership (hardcoded to 'jenkins'), but works for me.
            gsash Georg Sash added a comment -

            I have the exact same problem. this is very annoying.

            gsash Georg Sash added a comment - I have the exact same problem. this is very annoying.
            evernat evernat added a comment -

            In order to be fixed, it would be better to submit a pull request at github than just a patch here.

            I suppose that the pull request would be for this file:
            https://github.com/jenkinsci/jenkins/blob/master/rpm/SPECS/jenkins.spec

            evernat evernat added a comment - In order to be fixed, it would be better to submit a pull request at github than just a patch here. I suppose that the pull request would be for this file: https://github.com/jenkinsci/jenkins/blob/master/rpm/SPECS/jenkins.spec

            Code changed in jenkins
            User: Nicolas De loof
            Path:
            rpm/SPECS/jenkins.spec
            http://jenkins-ci.org/commit/jenkins/4335bd435f9e5258831c5631bfab2fd837fd7719
            Log:
            [FIXED JENKINS-12231] ensure right owner

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De loof Path: rpm/SPECS/jenkins.spec http://jenkins-ci.org/commit/jenkins/4335bd435f9e5258831c5631bfab2fd837fd7719 Log: [FIXED JENKINS-12231] ensure right owner
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #3174
            [FIXED JENKINS-12231] ensure right owner (Revision 4335bd435f9e5258831c5631bfab2fd837fd7719)

            Result = SUCCESS
            Nicolas De Loof : 4335bd435f9e5258831c5631bfab2fd837fd7719
            Files :

            • rpm/SPECS/jenkins.spec
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #3174 [FIXED JENKINS-12231] ensure right owner (Revision 4335bd435f9e5258831c5631bfab2fd837fd7719) Result = SUCCESS Nicolas De Loof : 4335bd435f9e5258831c5631bfab2fd837fd7719 Files : rpm/SPECS/jenkins.spec

            This solution is really bad for me and for anyone with a very big jenkins installation, as the chown is taking around 1hr for each jenkins upgrade.

            Maybe the script could skip the chown if there is a specific sysconfig variable set? (SKIP_CHOWN?)

            flozano Francisco Lozano added a comment - This solution is really bad for me and for anyone with a very big jenkins installation, as the chown is taking around 1hr for each jenkins upgrade. Maybe the script could skip the chown if there is a specific sysconfig variable set? (SKIP_CHOWN?)
            gsash Georg Sash added a comment -

            I guess excluding the "jobs" sub directory in the data location from the chown operation would solve this.

            gsash Georg Sash added a comment - I guess excluding the "jobs" sub directory in the data location from the chown operation would solve this.

            Still having the same problem:

            root     21289 21286  3 11:19 pts/0    00:00:02 chown -R jenkins /mnt/ebs/jenkins
            

            stuck for +1hr while updating jenkins:

              Updating   : jenkins-1.556-1.1.noarch                                                                                                                                                                                                                          263/505
            
            flozano Francisco Lozano added a comment - Still having the same problem: root 21289 21286 3 11:19 pts/0 00:00:02 chown -R jenkins /mnt/ebs/jenkins stuck for +1hr while updating jenkins: Updating : jenkins-1.556-1.1.noarch 263/505
            danielbeck Daniel Beck added a comment -

            Is there a reason the patch does not include /var/cache/jenkins? And that it's recursive is probably really unnecessary, as noted in JENKINS-23273.

            Francisco Lozano: Doesn't your /etc/sysconfig/jenkins define as JENKINS_USER the name of the Jenkins user?

            danielbeck Daniel Beck added a comment - Is there a reason the patch does not include /var/cache/jenkins? And that it's recursive is probably really unnecessary, as noted in JENKINS-23273 . Francisco Lozano: Doesn't your /etc/sysconfig/jenkins define as JENKINS_USER the name of the Jenkins user?
            olenz Olaf Lenz added a comment -

            I think that this issue is fixed. When setting the JENKINS_USER in /etc/sysconfig/jenkins, the ownership is set correctly. The problem about long times required to chown is handled in JENKINS-23273.

            olenz Olaf Lenz added a comment - I think that this issue is fixed. When setting the JENKINS_USER in /etc/sysconfig/jenkins, the ownership is set correctly. The problem about long times required to chown is handled in JENKINS-23273 .
            olenz Olaf Lenz added a comment -

            This is fixed since a while.

            olenz Olaf Lenz added a comment - This is fixed since a while.

            Code changed in jenkins
            User: Nicolas De loof
            Path:
            SPECS/jenkins.spec
            http://jenkins-ci.org/commit/packaging/144b7bd6ec71092162030e648c02e879506f81fa
            Log:
            [FIXED JENKINS-12231] ensure right owner
            Originally-From: jenkins-ci.org/commit/core/4335bd435f9e5258831c5631bfab2fd837fd7719

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De loof Path: SPECS/jenkins.spec http://jenkins-ci.org/commit/packaging/144b7bd6ec71092162030e648c02e879506f81fa Log: [FIXED JENKINS-12231] ensure right owner Originally-From: jenkins-ci.org/commit/core/4335bd435f9e5258831c5631bfab2fd837fd7719

            Code changed in jenkins
            User: Vojtěch-Zweibrücken-Šafařík
            Path:
            rpm/build/SPECS/jenkins.spec
            http://jenkins-ci.org/commit/packaging/d7b16bc1f25c534572ef238a885bb28571455b99
            Log:
            JENKINS-23273 Revert sticky bit to not reopen JENKINS-12231 like
            situations

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Vojtěch-Zweibrücken-Šafařík Path: rpm/build/SPECS/jenkins.spec http://jenkins-ci.org/commit/packaging/d7b16bc1f25c534572ef238a885bb28571455b99 Log: JENKINS-23273 Revert sticky bit to not reopen JENKINS-12231 like situations

            People

              Unassigned Unassigned
              fernando Fernando Dobladez
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: