Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
Windows 2003 R3
Java 1.6.0_26
Apache httpd 2.2 as frontend (apj13 proxy)
Description
After moving to a Jenkins installation that runs as a service. I noticed it now had the option to download new versions of itself and upgrade. I tried that with 1.452 and was a bit confused that it restarted but still showed 1.452 as version number. But also gives me the option to downgrade to 1.452.
After a couple more tries I think I can conclude that what happens is that it downloads the new version just fine (as jenkins.war.tmp) and copies the current version fine as well (jenkins.war.bak). But it never actually gets around to replacing the current running version with the new one.
This appears to be the relevant part of the jenkins.err.log:
INFO: Starting the installation of jenkins.war on behalf of kpe Mar 19, 2012 9:17:19 AM hudson.model.UpdateCenter$UpdateCenterConfiguration download INFO: Downloading jenkins.war Mar 19, 2012 9:17:19 AM hudson.model.UpdateCenter doSafeRestart INFO: Scheduling Jenkins reboot Mar 19, 2012 9:17:40 AM hudson.model.UpdateCenter$DownloadJob run INFO: Installation successful: jenkins.war
But I am a bit confused on how this would ever actually work on Windows? Since files are generally locked up pretty tight. So replacing or overwriting a file that Java is actively using would be practically impossible. And instead it would require some sort of utility running before starting Jenkins to replace the war file with the newly downloaded one.
Attachments
Issue Links
Activity
Hey Daniel,
I've managed to reproduce this issue multiple times using a full admin windows account while using the latest copy of winsw (1.18). It seems to me that the process that writes jenkins.war.tmp fails silently. I can confirm that the correct update is being downloaded, stored as jenkins.war.tmp and making a copy of the old file as jenkins.war.bak.
I suspect it's happening due to the jenkins.exe still holding a file handle on the original war file and fails silently based off how I understand what's going on in the core code:
https://github.com/jenkinsci/jenkins/blob/cf64ba04fe8b0312bb4492766d62b5a00b790432/core/src/main/java/hudson/lifecycle/Lifecycle.java#L137-L170
It may be helpful to have the
canRewriteHudsonWar()
function report success vs failure in the logger. I guess it would be best to avoid throwing an exception to help prevent introducing API breakage.
The windows event viewer will throw the following details when the service is terminated (that is, when you check the restart box), but even the OS logs fail to report a problem, so this fails silently by all accounts right now. No additional errors are reported in the wrapper log. Here is the windows event at the time the JVM is restarted after the update is downloaded to the system:
Log Name: Application Source: Jenkins Date: 6/8/2016 2:12:14 PM Event ID: 0 Task Category: None Level: Information Keywords: Classic User: N/A Computer: reubenWin Description: Child process [4860 - C:\jenkins\java\jre1.8.0_92\bin\java -server -d64 -Xrs -Xms2048m -Xmx2048m -XX:+AlwaysPreTouch -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djenkins.model.Jenkins.logStartupPerformance=true -Dhudson.udp=-1 -Dhudson.DNSMultiCast.disabled=true -jar "C:\jenkins\jenkins.war" --httpListenAddress=0.0.0.0 --httpsPort=-1 --httpPort=8080 --ajp13Port=-1 --webroot=C:\jenkins\webroot] terminated with -1073741510 Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Jenkins" /> <EventID Qualifiers="0">0</EventID> <Level>4</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2016-06-08T18:12:14.000000000Z" /> <EventRecordID>1159</EventRecordID> <Channel>Application</Channel> <Computer>reubenWin</Computer> <Security /> </System> <EventData> <Data>Child process [4860 - C:\jenkins\java\jre1.8.0_92\bin\java -server -d64 -Xrs -Xms2048m -Xmx2048m -XX:+AlwaysPreTouch -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djenkins.model.Jenkins.logStartupPerformance=true -Dhudson.udp=-1 -Dhudson.DNSMultiCast.disabled=true -jar "C:\jenkins\jenkins.war" --httpListenAddress=0.0.0.0 --httpsPort=-1 --httpPort=8080 --ajp13Port=-1 --webroot=C:\jenkins\webroot] terminated with -1073741510</Data> </EventData> </Event>
I've attached a copy of my jenkins.xml file if that helps:
jenkins.xml
Note that I intentionally use custom folder paths to help prevent windows from locking up files in use, hence the separation of individual directories like this:
c:\jenkins c:\jenkins\webroot c:\jenkins\tmp c:\jenkins\data
Halvor Platou
added a comment - It seems that this happens when when running with a custom JENKINS_HOME. If, so the "jenkins.copies" file is written to JENKINS_HOME and will not be used by the service wrapper when restarting. I have created a pull-request [#2992|https://github.com/jenkinsci/jenkins/pull/2992] with a proposed solution. Using environment variable BASE which is set by the service wrapper.
Halvor Platou
added a comment - It seems that this happens when when running with a custom JENKINS_HOME. If, so the "jenkins.copies" file is written to JENKINS_HOME and will not be used by the service wrapper when restarting. I have created a pull-request [#2992| https://github.com/jenkinsci/jenkins/pull/2992 ] with a proposed solution. Using environment variable BASE which is set by the service wrapper. Code changed in jenkins
User: hplatou
Path:
core/src/main/java/hudson/lifecycle/WindowsServiceLifecycle.java
http://jenkins-ci.org/commit/jenkins/0efdf8fb4f8c56f1f32fb390c472cb2e98e67f56
Log:
JENKINS-13153 - Use directory from env:BASE when writing jenkins.copies (#2992)
JENKINS-13153 - Use directory from env:BASE when writing jenkins.copies
Anyone still experiencing this on recent Jenkins versions, with up to date jenkins.exe?