-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Powered by SuggestiMate
Happens semi-random, but whenever I leave the Jenkins page for an amount of time and then come back and hit refresh, the CSS seems to break (see attached image).
Hitting refresh again does NOT fix it. However, holding shift while refreshing (forced refresh) fixes the issue and the page goes back to looking normal (hitting normal refresh works fine then).
I've tried it in different browsers (and even a co-worker's computer) and it is happening there too.
- duplicates
-
JENKINS-17684 Dashboard web pages don't render correctly in Chrome because of bad cache/session
-
- Reopened
-
-
JENKINS-22442 Jetty exploding war to /tmp is a bad idea
-
- Resolved
-
- is related to
-
JENKINS-20858 Images missing from Jenkins UI
-
- Closed
-
[JENKINS-17526] Broken CSS when reloading Jenkins after a time of inactivity
I also have this issue with 1.480.3 LTS. With Jenkins running on Windows XP as service.
If it makes any difference, I've found that some elements seem to lose their styling before others. In particular the breadcrumb navigation buttons at the top left of the screen seem to lose their styling first. This is quite annoying as the unstyled list of navigation items spans the width of the screen and overlays clickable elements on some screens preventing them from being clicked. I have also observed the entire page being unstyled as with above screenshot.
+1 for this issue appearing in 1.480.3 LTS. I installed the build via a debian package (ubuntu linux OS).
My feeling is that this issue should have a higher priority than minor as it gives the impression that the 1.480.3 "LTS" build is unpolished. However as noted above, using shift + refresh does make the problem go away.
This looks similar to JENKINS-17684. There is other interesting information related to the bug there.
Same issue, running on Ubuntu 12.04 LTS.
Additionally, ONLY when the CSS is broken, I can delete existing users. Other times, the "delete" link on left side is not visible. Does anyone else also have this issue ? Are they related ?
Same here running on Windows XP host (as a service) and viewing no client machines using Chrome / FF.
Closing the tab and opening a new one appears to fix the issue.
We're running this in a project with 5 teams of about 2/3 developers per team and we all experience this issue. Simple refresh doesn't work (even with cache turned off under Chrome), but a ctrl-F5 seems to have some effect.
FYI, I've just upgraded to v1.517 and have not as yet seen the issue re-appear.
The fix for this should be in 1.518, so you may well still see this problem occur in 1.517.
Can confirm that with the latest version (1.538) as you can see on the screenshot here: https://dl.dropboxusercontent.com/u/617077/jenkins_css_broken.PNG
It seems that accessing the css files seems to return a HTTP 404 like for "http://<host>/static/1a63fb46/css/style.css" and other files as well. A restart of the whole software seems to fix that.
After upgrading to 1.538, I was getting missing files too with URL (.../static/...). A full reboot of the server resolved it.
I'm getting the same issue in 1.538 too.
https://dl.dropboxusercontent.com/s/ze1soaao4zbg8ig/jenkins-css.png
This is very annoying and I have to be careful to not press F5.
The server is generating invalid URLs to static resources (e.g. http://touros:8080/static/38c6342f/images/24x24/grey.png), that gives 404 error.
A service reboot resolve the problem for a while.
This is happening on 1.539. Most CSS, JavaScript and images are failing to load.
The resources that succeed have the url formats:
http://myserver.com:8080/adjuncts/2103c023/org/kohsuke/stapler/rest-of-url
or
http://myserver.com:8080/static/2103c023/plugin/rest-of-url
The resources that fail have the url format:
http://myserver.com:8080/static/2103c023/rest-of-url.
Bind.js, jquery.full.js, breadcrumbs.js, breadcrumbs.css and some plugin images are the only files loading for me.
Clearing cache, force reloading, clearing cookie, logging out, and opening a different browser type does NOT fix the issue for me. I had to restart Jenkins.
This is on Windows 2008 R2 Standard Server Service Pack 1.
I have the same problem with version 1.540 on Mac Os X 10.9
Sincerely
GJean
Is this going to be fixed anytime soon? Jenkins is pretty much unusable in this state, e.g. you cannot submit changes to configuration.
I am very close to switching to Hudson.
Same problem here. Debug info attached.
- Jenkins 1.541.
- Mac OS X 10.8.5.
System Properties: https://dl.dropboxusercontent.com/u/4036736/System%20Properties.txt
Thread Dump: https://dl.dropboxusercontent.com/u/4036736/Thread%20Dump.txt
I suggest most people to first take a look in the TEMP folder on the jenkins server machine.
Are you cleaning your TEMP directory? Do you have any scripts running that periodically cleans the TEMP directory? Or does an admin sometimes clean the directory or run tools like CCleaner (on Windows), etc... ?
This applies esp. to people running jenkins using the (embedded) Jetty. I guess people running jenkins in tomcat etc. don't have the issue?
When running the Windows service, jetty extracts the war into (example) : TEMP\jetty-0.0.0.0-8080-jenkins.war--any-\webapp
It serves those files (images, .css, etc...) while running.
If you cleanup your TEMP - or at least some files from jetty's temp directory - while jenkins is still running, you'll get 404 errors, because jetty can't find the requested files anymore.
Issue JENKINS-20858 has someone else confirming that clearing out his $TEMP caused the missing images. Missing .css files is similar. (actually, just anything served by jetty may return error 404 after clearing tmp)
We did some investigation on this issue. It turned out that this indeed happens when the jetty... directory in $TEMP is deleted (or otherwise curupted?)
With us this occurs every night after upgrade of jenkins and plugins last week (from 1.539 to 1.541 )
Roll back of jenkins does not help.
Could it be caused by some plugin?
Can we confirm this is only when running using the embedded Jetty? If I can switch to using Tomcat, I will do that. Otherwise, I will have to end up switching to Hudson.
I have to revise my findings.
We figured out that a cron job indeed cleaned up the $TEMP.
Since we didn't have this problem in the past my question was since when are the jetty files put to $TEMP?
Where was it before, and why did it change?
There are two possible work-arounds on Mac OS X:
1. Disable daily tmp cleaning by setting daily_clean_tmps_enable=NO in /etc/periodic.conf
2. Changing Jetty's tmpdir.
I've submitted a Pull Request for option 2: https://github.com/jenkinsci/jenkins/pull/1061
I just ran into this issue again on OS X. It's happened several times in the past, and restarting Jenkins was the only way to resolve it.
I saw the same situation.
I have two different version of Jenkins, ver 1.538 and ver 1.542, and now both Jenkins are in the same problem.
(These Jenkins were fine at the end of last year…)
Both Jenkins are up for 1 or 2 month.
I wonder this is because Jetty's behavior.
The answer is moving the temp dir for Jetty outside of the normal temp directory which gets periodically cleaned. If you examine Greg's pull request you can see which files to change to move the temp dir for jetty and I can confirm this fixes the problem.
To implement that solution is to edit /Library/Application Support/Jenkins/jenkins-runner.sh (you'll need su priveleges to do so) and add this line to the middle of the file near the lines that are similar:
tmpdir=`$defaults tmpdir` && javaArgs="$javaArgs -Djava.io.tmpdir=${tmpdir}"
You'll need to create a temp directory for Jenkins (/Users/Shared/Jenkins/temp in my example) and give ownership to Jenkins:
sudo mkdir -p /Users/Shared/Jenkins/temp
sudo chown jenkins:jenkins /Users/Shared/Jenkins/temp
Then you need to set that directory as default:
defaults write /Library/Preferences/org.jenkins-ci tmpdir /Users/Shared/Jenkins/temp
Restart Jenkins and the problem will be gone for good.
Dale, thank you for your information.
My Jenkins is running on CentOS, installed via RPM package. So, I'm try to modify init script and going to report the result.
I'm on windows as my previous comment elaborated on. I thought it worthwhile to mention that I no longer have this issue.
The disappearance, for me, might be related to increasing my jvm memory and jvm permgen memory. I had noticed in my jenkins.err.log files, I was getting perm gen space and another out of memory error. It is possible that increasing those values has alleviated the symptoms for me.
Code changed in jenkins
User: Greg Albrecht
Path:
osx/Library/Application Support/Jenkins/jenkins-runner.sh
osx/scripts/postinstall-launchd-jenkins
http://jenkins-ci.org/commit/jenkins/95842fd6b6fe493da6bbb12faa0ec2c5c314f473
Log:
JENKINS-17526 Relocating Jetty/Java tmpdir for Mac OS X.
Code changed in jenkins
User: Olivier Lamy
Path:
osx/Library/Application Support/Jenkins/jenkins-runner.sh
osx/scripts/postinstall-launchd-jenkins
http://jenkins-ci.org/commit/jenkins/7c51cec55649b0e46047cb5e3198b66c3bdd94d5
Log:
Merge pull request #1061 from OnBeep/feature/ampledata-mac_os_x_tmp
JENKINS-17526 Relocating Jetty/Java tmpdir for Mac OS X.
Compare: https://github.com/jenkinsci/jenkins/compare/5727f287e245...7c51cec55649
Code changed in jenkins
User: Olivier Lamy
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/0c9d7dbafe0724ad4582a09c64187cf5c6a4ec6a
Log:
changelog entry for JENKINS-17526
Integrated in jenkins_main_trunk #3171
JENKINS-17526 Relocating Jetty/Java tmpdir for Mac OS X. (Revision 95842fd6b6fe493da6bbb12faa0ec2c5c314f473)
changelog entry for JENKINS-17526 (Revision 0c9d7dbafe0724ad4582a09c64187cf5c6a4ec6a)
Result = SUCCESS
gba : 95842fd6b6fe493da6bbb12faa0ec2c5c314f473
Files :
- osx/scripts/postinstall-launchd-jenkins
- osx/Library/Application Support/Jenkins/jenkins-runner.sh
Olivier Lamy : 0c9d7dbafe0724ad4582a09c64187cf5c6a4ec6a
Files :
- changelog.html
If you are on CentOS/RHEL or similar, do not modify the init script directly. Also do not copy the MacOS directions directly. There is a "configuration" file that you can use to add this setting in, which will not be overwritten on future upgrades, and is the correct place to put this change: /etc/sysconfig/jenkins.
[root@grays ~]# grep tmpdir /etc/sysconfig/jenkins
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Djava.io.tmpdir=/var/run/jenkins"
Tommy
Jenkins uses /tmp by default, tricky but shouldn't matter unless you have cleanup crons/scripts running. I have changed `/etc/default/jenkins` to point the tmp folder somewhere else (/var/lib/jenkins/tmp, /var/run/jenkins and even /opt/jenkins) but even then it loses the static assets (the whole 0.0.0.0------jetty unpacked war!)
If I create the mentioned war folder Jenkins fails to even start. Strange stuff...
TL;DR: This appears to be something else and not because its in the /tmp folder...
This issue has been pointed to by the release notes for 1.549, but this is still marked as "In Progress" and "Unresolved." What is the actual status? I'd like to know before I update our instance. Thank you.
I've also just downloaded and updated to version 1.549, RPM for CentOS jenkins-1.549-1.1.noarch.
But it seems there is no change in /etc/default/jenkins and restored directory is still the same, /tmp/jetty-xxxxx. So I wonder this issue is fixed or not.
My workaround is excluding /tmp/jetty* directory from tmpwatch cron with -X '/tmp/jetty*' option.
I was just able to reproduce this issue in version 1.549 where it was supposed to be fixed. I am running it on Mac OSX Mountain Lion.
Still seeing this issue with Jenkins 1.549. Appears unresolved. Running Jenkins on MacOS X Mountain Lion.
I think that this is the same issue as JENKINS-20682. I added some notes regarding how that might be fixed but don't have the time at the moment to delve into the workings of winstone.jar to make a production ready fix.
This seems to have been resolved on Jenkins 1.555: https://github.com/jenkinsci/jenkins/commit/7c51cec55649b0e46047cb5e3198b66c3bdd94d5
The commit mentioned only fixes Mac OSX, however I have also seen this issue on CentOS 6 (or probably any other Linux or Unix) with tmpwatch installed. I would strongly recommend defaulting to /var/run/jenkins or something similar, across all *nix like OS's. The current workaround is to either edit /etc/default/jenkins to change the tmpdir (similar to the commit), or edit /etc/cron.daily/tmpwatch to exclude it as @akiko_pusu mentioned above. As I don't think the Jenkins package should be futzing with the tmpwatch cron job, it makes the most sense, in my opinion, to default to a different tmpdir location. Note that this would also require the directory to be created with the proper permissions. The /var/run/jenkins directory could be created by the package, but it should be checked and created if necessary during the init script because some OS's (Solaris) tend to mount /var/run on tmpfs.
The fix for JENKINS-22442 restores the previous behaviour and 1.558 now honours the --webroot commandline argument again.
Fix for JENKINS-22442 in 1.558 and 1.554.1 should resolve this as well. Therefore marking this as duplicate.
Code changed in jenkins
User: Greg Albrecht
Path:
Library/Application Support/Jenkins/jenkins-runner.sh
scripts/postinstall-launchd-jenkins
http://jenkins-ci.org/commit/packaging/c8fb9d70124277b3d64e19a384171fcd396792e3
Log:
JENKINS-17526 Relocating Jetty/Java tmpdir for Mac OS X.
Originally-From: jenkins-ci.org/commit/core/95842fd6b6fe493da6bbb12faa0ec2c5c314f473
Code changed in jenkins
User: Olivier Lamy
Path:
Library/Application Support/Jenkins/jenkins-runner.sh
scripts/postinstall-launchd-jenkins
http://jenkins-ci.org/commit/packaging/c932cd9363357fc83e993b1da2d565ed2893aee1
Log:
Merge pull request #1061 from OnBeep/feature/ampledata-mac_os_x_tmp
JENKINS-17526 Relocating Jetty/Java tmpdir for Mac OS X.
Originally-From: jenkins-ci.org/commit/core/7c51cec55649b0e46047cb5e3198b66c3bdd94d5
We are facing similar issue with Jenkins. Logged in users are working fine and able to see the UI properly. But unlogged in users are not able to view the UI properly and css/images are messed up for them. The cache containing static content is not available for unlogged in users.
Anyone aware of this issue?
I'm also seeing this issue, with the same "workaround" to resolve.