[JENKINS-21942] Unreliable defaulting of Jenkins.workspaceDir

[timja]

Jenkins.workspaceDir is supposed to default to $JENKINS_HOME/workspace/ on new installations: the "modern" location, consistent with that of slaves. But if you do not save the Jenkins global configuration during the first startup, on the next startup $JENKINS_HOME/jobs/ exists yet $JENKINS_HOME/config.xml does not, so the "compatibility" code kicks in and the old location is used!

Just setting this field to the new value in the instance initializer probably does not suffice, since installations upgraded from before the introduction of this field would be incorrectly switched to the new value.

Probably suffices to adjust the check to also check for the existence of $JENKINS_HOME/config.xml, since most old installations would have saved this file at least once.

---

Originally reported by jglick, imported from: Unreliable defaulting of Jenkins.workspaceDir

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

jglick:

Seems like Jenkins 1.420 is the last “old version”.

[timja]

jglick:

Should be rechecked in 2.x after changes relating to the installation wizard, which might have forced a save.

[timja]

danielbeck:

Well, there's always -Djenkins.install.runSetupWizard=false for the chefs among us.

[timja]

jensk:

this seems to be open for quite a long time - any updates?

[timja]

jglick:

Not reproducible in 2.46.3 when using the setup wizard; something is saving $JENKINS_HOME/config.xml. Still, might affect installations created in 1.x under the conditions mentioned, or even new installations created using special Docker images, etc. etc., so probably best to define an administrative monitor for this.

[timja]

batmat:

jglick I couldn't reproduce either with 2.112, or a local build for https://github.com/jenkinsci/jenkins/pull/3364

I can confirm the config.xml gets created without any user interaction during Jenkins startup in any case now, even . Do we want to close this, do you still think it makes sense to do additional things here, like the admin monitor you're talking about? If so, care to clarify what you mean that monitor would do?

Unassigning myself, and removing from Essentials milestone 1 for now at least as AFAIU there's nothing to fix here.

Thanks!

[timja]

jglick:

batmat yes I already said it is not reproducible in interactive setup; my concern was about new installations created via Docker or config-as-code generally.

[timja]

jglick:

batmat in some ways this is actually worse after JENKINS-50164, because if for example you had a working instance and then deleted $JENKINS_HOME/config.xml (say, to fix a security lockout), Jenkins will quietly reset those values to

  ${ITEM_ROOTDIR}/workspace
  ${ITEM_ROOTDIR}/builds

and there is no way to fix the OLD_DEFAULT_WORKSPACES_DIR from the GUI.

Probably we should just throw out the old default and unconditionally default to DEFAULT_WORKSPACES_DIR. There is little real compatibility risk here even for installations that had been using the old location—they will have some stranded workspaces, and the first new build of each job will need a full SCM clone rather than update, but that seems a tolerable price to pay to fix this once and for all.

[timja]

davida2009:

batmat I see this message in our console log:

Feb 18, 2019 8:29:06 AM WARNING jenkins.branch.WorkspaceLocatorImpl getWorkspaceRoot
JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory ‘${ITEM_ROOTDIR}/workspace’; switch to ‘${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}’ as in JENKINS-8446 / JENKINS-21942

I don't understand the message. Please will you suggest how I can fix the problem in our Jenkins installation?

[timja]

dmolesuc3:

I'm seeing the same, in a Docker image configured with JCasC.

 

[timja]

kerrhome:

batmat I'm seeing the same.  Do we know what needs to be done to correct this?  Per jglick on JENKINS-2111 this is not something we should ignore.

[timja]

batmat:

I think we are going to try and look into this, but anyone feel free to give it a shot if you feel like it. See https://github.com/jenkinsci/jenkins/pull/3364 partly for hints, as it touches mainly the related code area.

Fixing this should not be too hard for an experienced Java developer.

*UPDATE: also, dmolesuc3 it would be very interesting if you can provide a GitHub repo for such a Docker image demonstrating the issue. Definitely should help fixing this more quickly.
UPDATE2: as said by Jesse too, if you are seeing this, this would also mean you are building on the master node, which is generally strongly discouraged.*

[timja]

jglick:

My suggestion as of 2018-04-24 is to just toss out the partially broken compatibility code and only mention the recommended location in the code. Simpler and probably good enough.

[timja]

integer:

Now it's impossible to run Jenkins on relative dir path. If i pass into jenkins rule target/somedir it fails because Jenkins instance itself can work without issues, but this check throws and fails.
Fresh Jenkins object has no config.xml in JenkinsRule, then checks {{ checkRawBuildsDir(buildsDir);}} where buildDir is "${ITEM_ROOTDIR}/builds" by default
(stacktrace from 2.176.4)

08:51:16 org.jvnet.hudson.reactor.ReactorException: java.io.IOException: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path
08:51:16    at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282)
08:51:16    at jenkins.InitReactorRunner.run(InitReactorRunner.java:48)
08:51:16    at jenkins.model.Jenkins.executeReactor(Jenkins.java:1129)
08:51:16    at jenkins.model.Jenkins.(Jenkins.java:936)
08:51:16    at hudson.model.Hudson.(Hudson.java:85)
08:51:16    at org.jvnet.hudson.test.JenkinsRule.newHudson(JenkinsRule.java:675)
08:51:16    at org.jvnet.hudson.test.JenkinsRule.before(JenkinsRule.java:402)
08:51:16    at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:595)
08:51:16    at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
08:51:16    at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
08:51:16    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
08:51:16    at java.lang.Thread.run(Thread.java:748)
08:51:16 Caused by: java.io.IOException: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path
08:51:16    at jenkins.model.Jenkins.loadConfig(Jenkins.java:3050)
08:51:16    at jenkins.model.Jenkins.access$1200(Jenkins.java:310)
08:51:16    at jenkins.model.Jenkins$13.run(Jenkins.java:3145)
08:51:16    at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
08:51:16    at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
08:51:16    at jenkins.model.Jenkins$5.runTask(Jenkins.java:1095)
08:51:16    at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
08:51:16    at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
08:51:16    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
08:51:16    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
08:51:16    ... 1 more
08:51:16 Caused by: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path
08:51:16    at jenkins.model.Jenkins.checkRawBuildsDir(Jenkins.java:3101)
08:51:16    at jenkins.model.Jenkins.loadConfig(Jenkins.java:3047)
08:51:16    ... 10 more

[timja]

jglick:

A relative path for $JENKINS_HOME? I would not consider that supported. Please use absolute paths only.

[timja]

martinm82:

batmatjglick what is the proposed solution for getting rid of this log message

[...]
jenkins.InitReactorRunner$1#onAttained: Completed initialization
WARNING    j.branch.WorkspaceLocatorImpl#getWorkspaceRoot: JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory '${ITEM_ROOTDIR}/workspace'; switch to '${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}' as in JENKINS-8446 / JENKINS-21942}

We have the following Docker image:

FROM jenkins/jenkins:2.190.3
USER root
# Install docker dependencies
RUN apt-get update && apt-get install --no-install-recommends -y libltdl7 && rm -rf /var/lib/apt/lists/*
USER jenkins

COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt

ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false -Dhudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID=true -Dhudson.model.UpdateCenter.never=true -Dhudson.slaves.WorkspaceList=_ -Dhudson.model.DirectoryBrowserSupport.CSP=\"default-src 'self'; style-src 'self' 'unsafe-inline';\""

COPY init.groovy.d/*.groovy /usr/share/jenkins/ref/init.groovy.d/

After running this container and running the init.d groovy scripts the log contains the above mentioned log message.

We don't run the wizard because we configure Jenkins with some Groovy init.d scripts. What is the way to get rid of this warning?

Appreciate your help.

[timja]

jglick:

Needs core changes I think.

[timja]

[Originally duplicated by: JENKINS-39670]

[timja]

[Originally related to: JENKINS-60969]