I've been struggling with an annoying "Jenkins/Tomcat/Windows" problem for a while now without reaching any solution.
I've installed Tomcat version 7.0.25 in a Windows 7 Enterprise machine and Jenkins 1.451 as a webapplication
running under Tomcat. I have just 4 jobs configured right now and all of then are using the "Always chekout a fresh copy" checkout strategy,
so everytime a job runs the content in /jobs//workspace gets deleted. But, there are situations in which the job fails to run because
it is unable to delete the /jobs//workspace/pom.xml file like you can see in this (edited) stacktrace:
Building in workspace C:\.hudson\jobs\<task name>\workspace
Cleaning local Directory .
java.io.IOException: Unable to delete C:\.hudson\jobs\<task name>\workspace\.\pom.xml
at hudson.Util.deleteFile(Util.java:237)
at hudson.Util.deleteRecursive(Util.java:287)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:73)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745)
at hudson.FilePath.act(FilePath.java:788)
at hudson.FilePath.act(FilePath.java:770)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:576)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
at hudson.model.Run.run(Run.java:1409)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Retrying after 10 seconds
Here you can see Tomcat locking the file as I told:
After some time Jenkins/Tomcat releases the lock on the pom.xml and i can execute the job again without any problem.
Does anyone know how to get around this ? Am i missing something ? Thanks in advance!
I changed to Windows Service installation, and the pom.xml never gets locked anymore.
Seems that this caused by Tomcat that somehow locks the pom.xml, although the build has finished.
Related
whenever I try to run gradle I get this error:
`Starting a Gradle Daemon, 3 stopped Daemons could not be reused, use --status for details
FAILURE: Build failed with an exception.
What went wrong:
A new daemon was started but could not be connected to: pid=DaemonInfo{pid=15005, address=[0afc2481-e15f-4c14-ad0a-ab04bb464abe port:46235, addresses:[/127.0.0.1]], state=Busy, lastBusy=1673266156479, context=DefaultDaemonContext[uid=c8f84860-9dea-4853-8963-824fa63d8e54,javaHome=/usr/lib/jvm/java-17-openjdk-armhf,daemonRegistryDir=/home/pi/.gradle/daemon,pid=15005,idleTimeout=10800000,priority=NORMAL,daemonOpts=--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=GB,-Duser.language=en,-Duser.variant]}, address= [0afc2481-e15f-4c14-ad0a-ab04bb464abe port:46235, addresses:[/127.0.0.1]]. See https://docs.gradle.org/7.5.1/userguide/troubleshooting.html#network_connection for more details.`
Everything was working fine until it suddenly broke without me making any changes in between.
I have tried the gradle troubleshooting guide, removing every gradle related file and reinstalling, different gradle versions, searching on the web also didnt give me any useful advice.
Any suggestions/ideas what might be causing this?
I updated my app to the latest TomCat 9 available and after update TomCat service failed to start successfully as Windows service. I just see 404 error when trying to open the TomCat app. Also there are no logs at all in the log directory!
If I start TomCat locally by the command tomcat9.exe" //TS//MyApp it started successfully.
OS: Windows 7 and Server 2012
Does anybody have any ideas of how to troubleshoot this issue?
I think I had the same problem.
By default, Tomcat9 installs a service to run as "LOCAL SERVICE" instead of "SYSTEM".
I found that if you go the properties on your service and select the "Log On" option "Local System account", that it will then start to work.
In my case tomcat wouldn't log what the problem was, so there was no easy way to diagnose this.
Maybe this could be diagnosed by running Process Monitor, then seeing what directory it wanted to log to, then change the permissions on that directory so that any user could write to it.
Tomcat has a new option to launch as s SYSTEM: --ServiceUser=LocalSystem
Add it to the tomcat9w.exe //IS// --ServiceUser=LocalSystem
We have a Jenkins instance running on Ubuntu that has several slaves in different systems. One of them is a Windows 7 host, having jenkins slave instance configured as a service.
We have a problem that when that machine is rebooted, master Jenkins doesn't realize it's gone. It looks to be just fine in the nodes view. Then, when a build is issued that is supposed to use that slave it gets stuck. If that is stopped, the next build fails immediately
Caused by: java.util.concurrent.TimeoutException: Ping started at 1457016721684 hasn't completed by 1457016961684
... 2 more
[EnvInject] - [ERROR] - SEVERE ERROR occurs: channel is already closed
When the slave has started up and it tries to connect back to master, connection is refused, and in the logs there is an error saying connection with that name already exists:
Server didn't accept the handshake: xxx is already connected to this master. Rejecting this connection.
There is issue JENKINS-5055 which claims a fix was committed allowing the same JNLP slave to reconnect without getting rejected, apparently this commit, and according to changelog, it was introduced in version 1.396 (2011/02/02). We are however using version 1.639 and seeing this. Somebody else seems to be seeing it as well. By looking at current codebase, I see where the error is coming from, but don't see the fix done in Jenkins-5055.
Any ideas on resolving this?
Edit: also asked on jenkins user mailing list, but no responses.
We faced the same issue. Used https://wiki.jenkins-ci.org/display/JENKINS/slave-status as workaround
Reinstalling the slave on a Windows Server 2012 R2 machine shows no signs of this behavior, so it seems that either there was a mistake done during installation steps or this is something caused by using a workstation Windows version.
Regardless, here were the steps to get it working, assuming a brand new installation of Windows, with no network connectivity, and master instance using a self-signed certificate:
Install JRE on the machine. If you have 64-bit operating system, install both 32-bit and 64-bit, otherwise go with 32-bit. Download link here
Install .NET 3.5 on the machine. This is needed by the Jenkins service. You can follow the steps outlined by my other answer for this.
Install Jenkins using Windows installer (.zipped) to C:\Jenkins. It can be downloaded from here.
Check your installation is responding by navigating to http://localhost:8080 . In case of trouble, check for logs in the jenkins folder. If there is a port conflict, edit jenkins.xml and change the httpPort to something else.
From the Windows computer, navigate to your master jenkins and configure a new node there.
Start a slave agent using Java Launch Agent in configure -> node screen (you need to be still using your Windows slave computer)
You should see a visible window opening. From there, select File -> Install as a service. (details and screenshots) If you experience an error without proper explanation, confirm .NET 3.5 is properly installed. If you see "WMI.WmiException: AccessDenied", save the jnlp file locally and start it from administrator prompt or otherwise with elevated privileges (details).
From the Administrative tools -> Services, stop and disable the Jenkins service, and stop Jenkins Slave Agent but leave it on Automatic so it will start up when starting up the computer.
This is only relevant if you're using a self-signed or otherwise problematic certificate:
download the previously mentioned Java Launch Agent file (.jnlp file) again and save it to C:\jenkins
open c:\jenkins\jenkins-slave.xml to your editor
change it to refer to your local .jnlp file by changing jnlp url parameter (file:/C:/jenkins/jenkins-slave.jnlp)
add -noCertificateCheck to parameters
replace the -secret parameter with -auth "user:pass", since otherwise automatic url get parameters will be added which will mess finding the .jnlp file
Start the Jenkins Slave Agent service again
For problems with jenkins slave service, check out jenkins-slave.err.log. For Windows Server 2012 R2, you can get the functionality of tail by using Get-Content .\jenkins-slave.err.log -Wait -Tail 10 in Powershell prompt. For older versions of Powershell, leave out -Tail 10.
I'm working on a fresh installation of stock DSpace 5.3 (Windows Server 2012, Tomcat 8.0, Maven 3.2.5, Ant 1.9.6). This particular instance will be a dark archive without Google Analytics enabled; we don't currently have a GA account or analytics key, although we plan to register one eventually for a separate public-facing instance.
As per the problem described in JIRA ticket DS-2718, DSpace hangs with the following message in dspace.log when I attempt to download a bitstream:
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# I/O exception (java.net.SocketException) caught when processing
request to {s}->https://www.google-analytics.com:443: Network is
unreachable: connect
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# Retrying request to {s}->https://www.google-analytics.com:443
Since we won't be using GA on this instance, disabling it in Spring is a good workaround until the issue is resolved. As per the instructions, I commented out the Google Analytics entry in dspace-5.3-src-release\dspace-xmlui\src\main\webapp\WEB-INF\spring\applicationContext.xml, disabled Tomcat and rebuilt DSpace. An initial attempt running mvn package -Dmirage2.on=true still produced the problem, so I tried a "ground up" rebuild:
cd d:\dspace-5.3-src-release\dspace
mvn clean package -U -Dmirage2.on=true
[successful build]
cd d:\dspace-5.3-src-release\dspace\target\dspace-installer
ant update
[successful update]
[copy webapps to Tomcat 8.0\webapps and start Tomcat]
Even after the rebuild, however, I'm still getting the same error, with the same java.net.SocketException in dspace.log.
Not sure why this isn't working. Have I missed a step or setting in the rebuild process so that the change to applicationContext.xml isn't being applied?
FWIW, I tried grepping for "google" in dspace-5.3-src-release\dspace-xmlui-mirage2 to see if this could be a Mirage 2 problem, but I don't see anything that looks relevant.
This isn't an answer to why you're still seeing the SocketException, but the real fix for the problem you're describing is to remove the default GA key from dspace-services/src/main/resources/config/dspace-defaults.cfg, see https://github.com/DSpace/DSpace/commit/5b84fef1ad789443d06c338558a92f854b20c8ef. Have you tried doing that?
The issue resolved itself after I ran mvn clean -Dmirage2.on=true in both [dspace-src] and [dspace-src]\dspace. I'm guessing that the issue originated on our end due to someone running a maven build from the wrong directory.
I've also removed the default key from dspace-defaults.cfg as suggested. Everything's now working.
I'm installing sonarqube on Windows Server 2012.
I have followed the following steps:
Downloaded sonarqube4.4 and extracted to C:\Sonarqube
Downloaded Java JDK 1.7.0_60 and jre 1.7.0_67 as well as jre7
Installed Windows SDK 7 and .NET Framework 4
Navigated to C:\sonar\bin\windows x86-64 and ran StartSonar.bat as an administrator, this ran ok with no output and Ihad to hot ctrl- Z to break
I then ran \windows-x86-64\InstallNTService.bat as an administrator and I am seeing the sonarQube services was launched, but failed to start.
Not sure what the problem is.
I believe you first ran \windows-x86-64\InstallNTService.bat successfully and then StartSonar.bat unsuccessfully (the inverse order of what you describe).
You probably have [this problem]: http://qualilogy.com/fr/wp-content/uploads/sites/2/2013/09/Sonar_ServiceLaunchError2.jpg
Windows could not start the Sonar service on Local Computer.
Error 1067: The process terminated unexpectedly.
In that case, the solution is to change the user/rights to launch the Sonar service: https://qualilogy.com/en/migrate-sonarqube-tomcat-to-windows-service/
Go to the Services window, find the Sonar service, and open the Properties windows to change the user it logs on as to one with sufficient permissions.
I was able to solve this problem by creating a new folder named “Temp” in C:\Windows\System32\config\systemprofile\AppData\Local\
The Log-File will show only
--> Wrapper Started as Service
Cleaning or creating >temp directory C:\Program Files (x86)\SonarQube\sonarqube\temp
<-- Wrapper Stopped
The SonarQube service was launched, but failed to start.
After a long search, I came up to this site http://zen-and-art-of-programming.blogspot.de/2013/03/installing-and-running-sonar-source.html.
Solution:
Navigate to C:\Windows\system32\config\systemprofile\AppData\Local\ and create the directory Temp
2: Set the user rights to full access
3: Run the StartNTService.bat