I decided to do some additional tracking of last known working version of jenkins.war where --webroot parameter took effect.
I downloaded previous versions and ran test to see which last known version set webroot to defined: /var/cache/jenkins folder.

Last Version to allow --webroot option was: v 1.534
jenkins-1.534.war - Pass!
jenkins-1.535.war - Fail!

INFO: Extract jar:file:/usr/share/jenkins/jenkins-1.535.war!/ to /tmp/jetty-0.0.0.0-8080-jenkins-1.535.war-any/webapp

So it appears this change was implemented in v.1.535 - 1.540 (current). I ran several test on 1.537, 1.538, 1.539 and same results.

changed component.

This is a big deal. If the operating system is set up to run tmpwatch with cron (our CentOS box is this way), files will start to get deleted from that /tmp/jetty-... folder and then Jenkins won't work correctly. Usually this is just icons and other images being broken in the UI, but sometimes it could be important jars missing.

Agree Ben, this it's a big problem.
Icons are missing and slaves couldn't start automatically, slave.jar is also missing.
/tmp is really a bad place for the extracted war file

Assigning to Kohsuke (who made the change to Jetty) for comment. I believe that this is an unintended consequence of moving to Jetty.

Note that this is not just a case of the war being exploded into TEMPDIR but I have observed that it continues to serve images etc from the old --webroot location based on the last non-Jetty version of Jenkins (see JENKINS-20858 ).

The symptoms are quite subtle and at a minimum this bug needs resolving before the next LTS release.

We are experiencing the same issue on Ubuntu 12.04.2: although we have moved from using /tmp, Jenkins still loses the icons, then the styles, overnight. Any idea of a timescale for this fix, please?

This is a serious issue, especially because https://issues.jenkins-ci.org/browse/JENKINS-20858 renders Jenkins essentially unusable until a reboot. I am having this issue on multiple Jenkins installations.

Can we please get a fix for this recently introduced major bug prioritized?

Thanks...

The Jetty documentation shows how the location of the temporary directories can be controlled
http://www.eclipse.org/jetty/documentation/current/ref-temporary-directories.html

I just did a quick experiment by adding a call to WebAppContext#setTempDirectory() in HostConfiguration#create()
https://github.com/jenkinsci/winstone/blob/master/src/java/winstone/HostConfiguration.java

i.e.

wac.setTempDirectory(new File("/var/cache/jenkins/temp"));

When jenkins.war was built with a version of winstone.jar containing that the Jetty temporary directory moved away from /tmp into /var/cache/jenkins/temp

That isn't a full solution to the problem because it needs hooking into the --webroot argument to jenkins.

There are other issues relating to how it works with multiple webapps (they should not share the same temp directory) and the usage of the temp folder is slightly different (it uses a /webapp subdirectory) to the old native winstone behaviour.

I don't know the internal plumbing of Winstone/Jenkins well enough to make a stab at a full fix for this.

I bumped into this issue trying to run jenkins in my NAS where the tmp is just 30MBs. Overriding the java system property (java.io.tmpdir) worked for me!

E.g.

nohup java -Djava.io.tmpdir=./webroot -jar jenkins.war --httpPort=9999 > ./jenkins.log 2>&1 &

The following worked better for me:

Set the jetty.home to Jenkins directory on the java opts when starting Jenkins

-Djetty.home=$JENKINS_HOME

Create a directory called "work" in Jenkins Home directory, or wherever you have set jetty.home

That will cause Jetty to use that work directory instead of whatever the java.io.tmpdir property is set to.

See JENKINS-22442
It should fix the issue reported here.

Duplicate of JENKINS-22442