I just had my Windows 2012R2 Jenkins 2.257 server fall to its knees for the second time in a week after something threw a spanner at Jenkins (started as a service). Jenkins was convinced that it needed to restart itself, which failed due to address already in use, so try again and again and again, dumping a new copy of winstone#.jar each time until out of disk space.
This bizarre behavior seems to be the result of how the Jenkins service is created by default, first failure: restart, second failure: restart, subsequent failures: restart.
For now I've set subsequent failures to 'take no action' - hopefully this will ease the pain.
I am still seeing this issue with Jenkins v 2.121.3. From jenkins release notes: https://jenkins.io/changelog-stable/#v2.107.1 I thought this had been fixed in v2.107.1
I noticed recently that there were several winstone jars in my /tmp. I manually removed all but the most recent. I then did a safeRestart of Jenkins and there were then 2 winstone jars in the /tmp directory of the master Jenkins node.
We are running the Jenkins war directly via a shell script
I'm not sure if it's related but I am also seeing some empty jetty directories with similar timestamps: