[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}

```</blockquote>
<p>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.</p>

<p>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.</p>


---
<details><summary><i>Originally reported by <a href="https://issues.jenkins.io/secure/ViewProfile.jspa?name=coofercat">coofercat</a>, imported from: <a class="no-jira-link-rewrite" href="https://issues.jenkins.io/browse/JENKINS-23273" target="_blank">RPM post-install should not do a "chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}"</a></i></summary>
<i><ul>
<li><b>assignee</b>: <img align="left" width="20" src="https://raw.githubusercontent.com/jenkinsci/artifacts-from-jira-issues/refs/heads/main/avatars/rarabaolaza.png" title="rarabaolaza's avatar" /> <a href="https://issues.jenkins.io/secure/ViewProfile.jspa?name=rarabaolaza">rarabaolaza</a>
<li><b>status</b>: Resolved
<li><b>priority</b>: Major
<li><b>component(s)</b>: packaging
<li><b>label(s)</b>: regression, rpm, yum
<li><b>resolution</b>: Fixed
<li><b>resolved</b>: 2017-04-04T13:23:10+00:00
<li><b>votes</b>: 13
<li><b>watchers</b>: 24
<li><b>imported</b>: 2025-11-26
</ul></i>
<details><summary>Raw content of original issue</summary>

<pre>
<p>The jenkins-1.565-1.1 RPM contains a post-install script with performs the following:</p>
<blockquote><div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># 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}
</pre>
</div></div></blockquote>
<p>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.</p>

<p>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.</p>
</pre>
</details>
</details>

Remote links associated with this issue:

oleg_nenashev:

Original comment link

Raw content of original comment:

Introduced by jenkinsci/jenkins@4335bd4

cburroughs:

Original comment link

Raw content of original comment:

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

danielbeck:

Original comment link

Raw content of original 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)

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)

coofercat:

Original comment link

Raw content of original 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.

danielbeck:

Original comment link

Raw content of original 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.

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.

tommythekid:

Original comment link

Raw content of original comment:

We are also being hit by this very lengthy chown process that is unnecessary.

In addition to that, if any of the stuff in any of the workspaces happen to have a symbolic link to something important like /etc or /root or /, the chown -R will follow the symbolic link and chown the destination file, which is BAD.

The chown should be removed, or at least it should be changed to "chown -hR"

~tommy

We are also being hit by this very lengthy chown process that is unnecessary.

In addition to that, if any of the stuff in any of the workspaces happen to have a symbolic link to something important like /etc or /root or /, the chown -R will follow the symbolic link and chown the destination file, which is BAD.

The chown should be removed, or at least it should be changed to "chown -hR"

~tommy

danielbeck:

Original comment link

Raw content of original comment:

tommythekid:

Are you sure about the symbolic links? My man chmod states (emphasis mine):

-H If the -R option is specified, symbolic links on the command line are followed. (Symbolic links encountered in the tree traversal are not followed.)

-h If the file is a symbolic link, change the user ID and/or the group ID of the link itself.

tommythekid:

Are you sure about the symbolic links? My man chmod states (emphasis mine):

-H If the -R option is specified, symbolic links on the command line are followed. (Symbolic links encountered in the tree traversal are not followed.)

-h If the file is a symbolic link, change the user ID and/or the group ID of the link itself.

tommythekid:

Original comment link

Raw content of original comment:

@Daniel Beck:

I think you are correct. Sorry for my misunderstanding.

~tommy

@Daniel Beck:

I think you are correct. Sorry for my misunderstanding.

~tommy

swf:

Original comment link

Raw content of original comment:

Updating jenkins on our environment took more than a hour because of this behaviour! This is very frustrating because everytime I need to explain the long downtime...

olenz:

Original comment link

Raw content of original comment:

I disagree that the behaviour should be removed. In a setting where Jenkins is run by a different user than "jenkins", this behaviour is absolutely required. Maybe it would make sense to first check whether any of the files need to be changed? Can somebody check how fast this command would run:

find /var/lib/jenkins -not -user jenkins

Then the code can be changed to something like

if find ${JENKINS_HOME:-/var/lib/jenkins} -not -user ${JENKINS_USER:-jenkins}; then
  chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}
fi
if find /var/log/jenkins -not -user ${JENKINS_USER:-jenkins}; then
  chown -R ${JENKINS_USER:-jenkins} /var/log/jenkins
fi

I disagree that the behaviour should be removed. In a setting where Jenkins is run by a different user than "jenkins", this behaviour is absolutely required.
Maybe it would make sense to first check whether any of the files need to be changed?
Can somebody check how fast this command would run:

find /var/lib/jenkins -not -user jenkins

Then the code can be changed to something like

if find ${JENKINS_HOME:-/var/lib/jenkins} -not -user ${JENKINS_USER:-jenkins}; then
  chown -R ${JENKINS_USER:-jenkins} ${JENKINS_HOME:-/var/lib/jenkins}
fi
if find /var/log/jenkins -not -user ${JENKINS_USER:-jenkins}; then
  chown -R ${JENKINS_USER:-jenkins} /var/log/jenkins
fi

swf:

Original comment link

Raw content of original comment:

Ok, I will check this on our environment.

danielbeck:

Original comment link

Raw content of original comment:

I disagree that the behaviour should be removed. In a setting where Jenkins is run by a different user than "jenkins", this behaviour is absolutely required.

Doesn't Jenkins fail to boot if it cannot write to its home directory?

A sane solution would be printing a warning if Jenkins is configured for a different user than owns the directory, or only chown-R'ing if the owner of JENKINS_HOME is different than expected – but not unconditionally. If only some files below JENKINS_HOME are owned by a different user, it's either intentional, or you broke it in some drunken craze, and I don't think the installer needs to fix it in either case.

I disagree that the behaviour should be removed. In a setting where Jenkins is run by a different user than "jenkins", this behaviour is absolutely required.

Doesn't Jenkins fail to boot if it cannot write to its home directory?

A sane solution would be printing a warning if Jenkins is configured for a different user than owns the directory, or only chown-R'ing if the owner of JENKINS_HOME is different than expected – but not unconditionally. If only some files below JENKINS_HOME are owned by a different user, it's either intentional, or you broke it in some drunken craze, and I don't think the installer needs to fix it in either case.

tommythekid:

Original comment link

Raw content of original comment:

If you are going to do the `find` you might as well `-exec` the chown instead of going back to a "chown -R" ... the only way that would make sense is if the find would stop immediately upon finding its first "match".  You are still traversing the entire filesystem with potentially thousands of files (in our case), causing undue delay. Our workaround for this issue is to stop jenkins and umount the `/var/lib/jenkins` filesystem prior to patching. Otherwise it takes a very long time.

I like the idea of changing it to a "warning" message, perhaps wrapped in big square of asterisks or something :-/ 

The package has a list of files that it would be installing. Perhaps the "correct" thing to do would be to run a for loop over that list of files to chown just those files to $JENKINS_USER, only if the $JENKINS_USER is not "jenkins" ... that way it won't traverse the entire filesystem, and it will only do anything if you are not running jenkins as jenkins 

~tommy

If you are going to do the `find` you might as well `-exec` the chown instead of going back to a "chown -R" ... the only way that would make sense is if the find would stop immediately upon finding its first "match". You are still traversing the entire filesystem with potentially thousands of files (in our case), causing undue delay. Our workaround for this issue is to stop jenkins and umount the `/var/lib/jenkins` filesystem prior to patching. Otherwise it takes a very long time.

I like the idea of changing it to a "warning" message, perhaps wrapped in big square of asterisks or something :-/

The package has a list of files that it would be installing. Perhaps the "correct" thing to do would be to run a for loop over that list of files to chown just those files to $JENKINS_USER, only if the $JENKINS_USER is not "jenkins" ... that way it won't traverse the entire filesystem, and it will only do anything if you are not running jenkins as jenkins

~tommy

coofercat:

Original comment link

Raw content of original comment:

Tommy's point about only chown'ing files that are in the RPM seems like a bright idea to me. I'm not sure if you can do an "rpm -qvl" during a post-install script though (has the package been installed enough to get this during post-install?). However, this would be a good solution.

In the short term, Tommy's other point about only attempting any sort of chown if the JENKINS_USER is not "jenkins" also makes a lot of sense, and would be easier to implement. It still penalises people who don't run as 'jenkins', but I'm guessing they're a pretty small minority. It'd help everyone else while working out the better solution in the future.

Cheers,

...Ralph

Tommy's point about only chown'ing files that are in the RPM seems like a bright idea to me. I'm not sure if you can do an "rpm -qvl" during a post-install script though (has the package been installed enough to get this during post-install?). However, this would be a good solution.

In the short term, Tommy's other point about only attempting any sort of chown if the JENKINS_USER is not "jenkins" also makes a lot of sense, and would be easier to implement. It still penalises people who don't run as 'jenkins', but I'm guessing they're a pretty small minority. It'd help everyone else while working out the better solution in the future.

Cheers,

...Ralph

benh57:

Original comment link

Raw content of original comment:

This change was never in the release notes. Was it released?

oleg_nenashev:

Original comment link

Raw content of original comment:

benh57 It was (around 2.53). I will make sure changelog is updated. Packaging is asynchronous, so it is hard to track changes in the core. I also want to start a developer ML thread for it

scm_issue_link:

Original comment link

Raw content of original comment:

Code changed in jenkins User: Oleg Nenashev Path: content/_data/changelogs/weekly.yml http://jenkins-ci.org/commit/jenkins.io/bd7e8598e4b85d84286ded5f2e6d71d08d8531ee Log: Add missing changelog entries for ~~JENKINS-23273~~ and ~~JENKINS-40693~~

Code changed in jenkins
User: Oleg Nenashev
Path:
content/_data/changelogs/weekly.yml
http://jenkins-ci.org/commit/jenkins.io/bd7e8598e4b85d84286ded5f2e6d71d08d8531ee
Log:
Add missing changelog entries for ~~JENKINS-23273~~ and ~~JENKINS-40693~~

scm_issue_link:

Original comment link

Raw content of original comment:

Code changed in jenkins User: Daniel Beck Path: content/_data/changelogs/weekly.yml http://jenkins-ci.org/commit/jenkins.io/d6c1369d8ebcdff4a9f126097ecc6a7c30ea1d86 Log: Merge pull request #921 from oleg-nenashev/changelog/missing-entries

Add missing changelog entries for ~~JENKINS-23273~~ and ~~JENKINS-40693~~

Compare: jenkins-infra/jenkins.io@14212ab...d6c1369

Code changed in jenkins
User: Daniel Beck
Path:
content/_data/changelogs/weekly.yml
http://jenkins-ci.org/commit/jenkins.io/d6c1369d8ebcdff4a9f126097ecc6a7c30ea1d86
Log:
Merge pull request #921 from oleg-nenashev/changelog/missing-entries

Add missing changelog entries for ~~JENKINS-23273~~ and ~~JENKINS-40693~~

Compare: jenkins-infra/jenkins.io@14212ab...d6c1369

scm_issue_link:

Original comment link

Raw content of original comment:

Code changed in jenkins User: Daniel Beck Path: content/_data/changelogs/lts.yml content/_data/changelogs/weekly.yml content/doc/upgrade-guide/2.60.adoc http://jenkins-ci.org/commit/jenkins.io/800435b6892e68f259f9c6ecbc54e79b1798c656 Log: Mention ~~JENKINS-23273~~, minor upgrade guide changes

Code changed in jenkins
User: Daniel Beck
Path:
content/_data/changelogs/lts.yml
content/_data/changelogs/weekly.yml
content/doc/upgrade-guide/2.60.adoc
http://jenkins-ci.org/commit/jenkins.io/800435b6892e68f259f9c6ecbc54e79b1798c656
Log:
Mention ~~JENKINS-23273~~, minor upgrade guide changes

[Original relates_to from Jira: JENKINS-12231]

[Original relates_to from Jira: JENKINS-26460]

Navigation Menu

Repository navigation

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

42 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

jenkins-infra-bot commented on Jun 2, 2014

jenkins-infra-bot commented on Jun 3, 2014

jenkins-infra-bot commented on Jun 3, 2014

jenkins-infra-bot commented on Jun 3, 2014

jenkins-infra-bot commented on Jun 3, 2014

jenkins-infra-bot commented on Jun 3, 2014

jenkins-infra-bot commented on Jun 4, 2014

jenkins-infra-bot commented on Aug 10, 2014

jenkins-infra-bot commented on Aug 12, 2014

jenkins-infra-bot commented on Nov 27, 2014

jenkins-infra-bot commented on Jan 16, 2015

jenkins-infra-bot commented on Jan 16, 2015

jenkins-infra-bot commented on Jan 16, 2015

jenkins-infra-bot commented on Jan 16, 2015

jenkins-infra-bot commented on Jan 19, 2015

42 remaining items

jenkins-infra-bot commented on Apr 24, 2017

jenkins-infra-bot commented on Apr 24, 2017

jenkins-infra-bot commented on Jun 12, 2017

jenkins-infra-bot commented on Jun 12, 2017

jenkins-infra-bot commented on Jun 21, 2017

jenkins-infra-bot commented on Nov 26, 2025

jenkins-infra-bot commented on Nov 26, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions