at the moment jenkins build my project and at the end the artifact is deployed on a remote tomcat via jenkins deploy plugin.
the problem is that after several redeployments this process fails (sometimes tomcat hangs or (un)deployment fails). in all cases stopping tomcat and manually undeploying helps.
Is there a way to stop tomcat before building/deploying, delete the old war and appfolder, and restart tomcat before deploy plugin wants to deploy the artifact?
thx in advance
You could write a batch file that does all the things mentioned:
stop tomcat
delete war files
start tomcat again
Then you can add a new pre/post build task in job configuration as execute batch and simply point it to run your batch file.
Added:
You can use PsExec - http://technet.microsoft.com/en-us/sysinternals/bb897553 It allows you to run processes remotely. Put batch on remote machine and from local one using Jenkins run sth like this: PsExec.exe \xx.xx.x.x C:\MyScript.bat
one addition to accepted answer:
it is important to reroute the output and error output of PsExec call (took me 2 days of debugging). See http://jenkins.361315.n4.nabble.com/remotely-executing-commands-td3476417.html
it seems that if called from java (like jenkins/tomcat) or .net PsExec hangs or quits with error. so the call should look like:
c:\someBatchWithPsExec.bat >>log.txt>&1
or explicitly on every call:
PsExec.exe -u [domain\remoteuser] -p [password] /accepteula \remoteMachine net [stop|start] Tomcat7 >>log.txt>&1
i guess if jenkins runs with domain\user u don't have to mention it in command?! (just tried it but it didn't work - the net commands fail)
Related
I have deployed my web application on company server by executing jar files then the project is running fine.But when i close the jar and again try to run the project on browser then client is not able to access the application.I want solution on this that if i close the jar then also client can access the application.
you can use this simple command to run a jar file as background service...
javaw -jar test.jar
after run this command you could not detect any change in cmd...and can close your command prompt. after 1 or 2 minute enter your URL in browser .. you will see your web program is running...
before run this command must be stop previously running jar for avoid same port conflict
for more details
When you close the cmd prompt, your java application will also be killed. To keep the java application running after closing the terminal you have to use the below command.
nohup java -jar app_name.jar &
just replace the app_name with your application name and run the command.
I am trying to experiment with a JHipster 4.3 app using Hazelcast. I have a setup of 3 Linux/CentOS7 VMs, each with latest 8 131 java/jdk on them. I build my war file for -Pprod and deploy to a dir at:
/var/jhiphaze/jhiphaze-0.0.1-SNAPSHOT.war
I have set this up as a service using systemctl. I am able to start | restart | etc.
I now have a need to debug into the application and would like to start the app up in debug mode. I read in the Spring Boot docs that I can place a file of the same base name with the extension of ".conf" and Spring Boot executable script will read the settings in the conf and start the app up with that. So I have a file:
/var/jhiphaze/jhiphaze-0.0.1-SNAPSHOT.conf
with the following line:
JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y"
This has no effect on the run of the war, it starts up fine but does not listen and the console out indicates that the app is not listening on 8787 (or any port).
I also tried on my windows workstation, simply running from cli using:
java -jar jhiphaze-0.0.1-SNAPSHOT.war
in the project /build dir with the jhiphaze-0.0.1-SNAPSHOT.conf placed in the same directory. It is ignored there as well. The same argument in the conf file work at the cli:
java -jar -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y jhiphaze-0.0.1-SNAPSHOT.war
works fine, pauses and waits for me to connect. Note that I used suspend=n for most of my attempts as I did not want the service start to fail while waiting for debugger to connect.
How can I get the executable war to recognize its partner .conf file?
I'm trying to run a function that we have to recycle our tomcat instance when doing a deploy to tomcat via bamboo. I thought that we would be able to use bamboo's ssh task to call our function tomcat recycle. I am able to run the function ssh connected to the box via putty but in bamboo we get the message:
ksh: tomcat: not found
Does anybody have any experience restarting tomcat automatically via bamboo? Is there a better way?
To restart tomcat via Bamboo
Create a ssh task -
You should be having tomcat service file in /etc/init.d (if you are using redhat)
/etc/init.d/tomcat start
/etc/init.d/tomcat stop
/etc/init.d/tomcat restart
should work
I'm having a issue with CI where after i deployed a build i can't get the new version to start. In Jenkins the console output just keeps spinning when it hit the part of the batch file to start the exe-file and then times out.
I have tried both to run it inside the batch file and from the SSH command line but i can't get it to start on our Windows server.
Any suggestions?
When I try to execute "vstest.console.exe" file in Jenkins CI (service mode), it responses
Error: Could not start test run for unit tests for Windows Store app:
Unit tests for Windows Store apps cannot be run from a service or non
interactive process. Please run unit tests from an interactive
process..
However it will be able to run successful if I execute the same command from a Command prompt.
So I want to ask if there is a way to open Command Prompt from a service such as Jenkins CI.
I have tried with "start ExecuteVSTest.bat /I /K /REALTIME" but the result is still the same.
I couldn't find a way to open Command Prompt from a service. However I am able to resolve the problem between Jenkins CI and "vstest.console.exe".
We just need to deploy Jenkins from the WAR file via Tomcat server instead of installing Jenkins service native package.
Since the Tomcat is running in the console mode so Jenkins CI won't have the same trouble when executing "vstest.console.exe" as when it run in service mode.