Hi all,
Not sure if anyone else is experiencing this, but I've been seeing a
problem with running Jenkins as a Windows service starting with 1.559.
Basically, if you trigger something that causes Jenkins to restart
(install/update plugins, use the /restart URI, etc.), Jenkins stops but
does not start again.
Since Windows doesn't have an atomic service restart, the Jenkins
Windows service wrapper (jenkins.exe) handles the "restart" option by
doing a "stop", waits, and then "starts". The wrapper's "stop" handling
finds the Process ID of Jenkins, recursively halts all the children
processes of that PID, then stops the PID itself.
However, since WindowsServiceLifecycle.java is what called "jenkins.exe
restart", this instance of the wrapper is a child of the parent Jenkins
PID, so the wrapper ends up stopping itself!
It seemed like the simplest fix was to modify the service wrapper such
that, as it recurses through all the child processes of the Jenkins
process, it compares its own execution path against that of the child
PID. If they match, the wrapper doesn't stop that particular PID.
I've tested this change on my company's three build machines and it
resolves the issue.* A WinSW pull request with the above fix has been
submitted, and the issue was captured as JENKINS-22685. Hopefully this
is the right list and tracker for the problem; I didn't see ones
specifically for WinSW.
*Testing was tricky at first until I figured out that
WindowsServiceLifecycle checks if the current jenkins.exe is different
than the one packaged as a resource in jenkins-core-xxx.jar, and, if so,
replaces the current with the packaged when Jenkins is restarted.
Updating the JAR by replacing the \windows-service\jenkins.exe with my
modified copy took care of it.
Thanks,
Jeff
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
