Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
windows
Description
java -Xrs -jar C:\Jenkins\slave.jar -jnlpUrl some-url -secret some_secret -jar-cache C:\Jenkins
...
java.io.IOException: Failed to write to C:\Users\Administrator\.jenkins\cache\ja
rs\7F\984FCCDA4AB099365EFD80FD06765D.jar
at hudson.remoting.FileSystemJarCache.retrieve(FileSystemJarCache.java:8
5)
Attachments
Issue Links
- is related to
-
-
- Resolved
-
Activity
Steve Down
added a comment - I've got the same problem: -jar-cache seems to be ignored as well, in version 2.28. My workaround for the problem is to add -Duser.home=pathtocache to the JVM arguments for the slave.
Steve Down
added a comment - I've got the same problem: -jar-cache seems to be ignored as well, in version 2.28. My workaround for the problem is to add -Duser.home=pathtocache to the JVM arguments for the slave. This problem's still present as of 1.538. For me it won't even print those errors, it accepts the -jar-cache argument, but totally ignores it.
I've tried it in many ways, IIRC c:\jenkins\cache, c:/jenkins/cache, /c/jenkins/cache, ./cache, cache, whatever, DOES NOT WORK in any way. It still puts the cache in the default location, i.e. c:\users\jenkins\.jenkins\cache, assuming the jar is started with the jenkins user.
Please fix this, I hate the way Jenkins scatters files all around the system.
Viktor Berke
added a comment - - edited This problem's still present as of 1.538. For me it won't even print those errors, it accepts the -jar-cache argument, but totally ignores it.
I've tried it in many ways, IIRC c:\jenkins\cache, c:/jenkins/cache, /c/jenkins/cache, ./cache, cache, whatever, DOES NOT WORK in any way. It still puts the cache in the default location, i.e. c:\users\jenkins\.jenkins\cache, assuming the jar is started with the jenkins user.
Please fix this, I hate the way Jenkins scatters files all around the system. Code changed in jenkins
User: Alex Slynko
Path:
src/main/java/hudson/remoting/Launcher.java
http://jenkins-ci.org/commit/remoting/1aca969d7a558d28483419a8b5f10b0c8ff0d889
Log:
[FIXED JENKINS-20093] Pass jar_cache config value
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/remoting/Launcher.java
http://jenkins-ci.org/commit/remoting/929d2c9f5058e66b18d462714ba6b6f415e2158a
Log:
Merge pull request #18 from alex-slynko-wonga/pass_jar_cache_config
JENKINS-20093 Pass jar_cache config value
Compare: https://github.com/jenkinsci/remoting/compare/425301511aeb...929d2c9f5058
Actually fixed in: https://github.com/jenkinsci/jenkins/commit/4137c46182a0652d2eed2897a1e797bdc3f8c7f9
Viktor Berke
added a comment - Thanks, I can verify that the jar files are indeed put in the correct location with 1.542, but the empty %USERPROFILE%\.jenkins\cache\jars folder is still being created each time a slave is started. Could you please check this out?
Viktor Berke
added a comment - Thanks, I can verify that the jar files are indeed put in the correct location with 1.542, but the empty %USERPROFILE%\.jenkins\cache\jars folder is still being created each time a slave is started. Could you please check this out? Code changed in jenkins
User: Oliver Gondža
Path:
http://jenkins-ci.org/commit/jenkins/5cf3e28c4885a86a4dad3463952e1aae34932f9c
Log:
[FIXED JENKINS-20093 JENKINS-19453 JENKINS-19004 JENKINS-8856] Noting retroactively
Backported as 23424ea7dbced486963a73d6bf56e8367ab779dd
Compare: https://github.com/jenkinsci/jenkins/compare/7d602d52b445...5cf3e28c4885
See
JENKINS-18578. The default value is I think poor. Fixing that would probably fix your original problem. That said, it sounds like there is a simple bug you found here; a full fix would have to include JENKINS-18956 (matching GUI).