I've been having this problem for a while. Vagrant boxes abort at the end of a Jenkins job. I've limited the job to just a script with
vagrant up
sleep 60
For 60 seconds vagrant boxes are running, but the second the job finishes vagrant boxes are aborted.
This behaviour is caused by the Jenkins process tree killer. I got it to work by running Jenkins as follows:
java -Dhudson.util.ProcessTree.disable=true -jar jenkins-1.537.war
Another (less global) work-around is to run vagrant as follows:
BUILD_ID=dontKillMe vagrant up
Makes sense in retrospect. Processes launched by a Jenkins job should be cleaned up at the end. Of course this would be a "gotcha" is you're attempting to use Jenkins to launch long running processes.
+1 for this question.
Maybe you are using an older version of the Jenkins plugin, but now it contains a checkbox called 'Don't Kill Me'. You have to check this to keep the vm up.
'jenkins config'
Related
I am having Jenkins running as a service and have a job to execute UFT tests on a remote slave. As part of the pipeline I am required to un-install our product, restart the slave, install the product (latest version) and start the test execution.
Since UFT tests need a dedicated UI, I am trying to launch a mstsc connection to the test VM from a temp VM. But since Jenkins is running as a service the mstsc process runs as a background process on the temp VM. Due to this UFT tests don't get a dedicated UI and some of the tests fail.
Tried running Jenkins using the war file instead of service. But after 30-40 mins or so the master slave connection drops.
Any workaround / tweak would be appreciated.
you need to run your jenkins remote agent(war) as a normal Process and not as a service, otherwise, as you mentioned there is no Desktop for them.
My Proposal:
Make sure the jenkins remote agent is running as a normal OS process (on both VMs). You can have a Windows Scheduled Task that launches this Process on Logon and Checks every 5 minutes if it is still alive (if not restarts it)
After the Temporary VM (Let's call it a Gateway) woke up your Test VM, the Test VM should execute a tscon command which will redirect the currently active RDP Session to the console (the Physical Monitor - which on Virtual machines well it's virtual). This will help you having your UI Session alive until the next restart, without having to bother about the Gateway
tscon here. Example: tscon rdp-tcp#1 /dest:console This can be solved again with a Scheduled Task which is executed At Logon (waiting a few Seconds just to make sure)
Have Caffeine.exe or MouseJiggle.exe running in the background as Processes (also launched at Logon) on your Test Computers to make sure the SCreen is never Locked or any Screen Saver is activated. Both tools are free.
If your Jenkins Connection drops that is a different issue has nothing to do with UFT. In my case this combination works perfectly fine. It is also easy to automate the installation of these things. Windows Batch and Vbs can do all these things for you. (Putting the mentioned tools to your %PATH% and creating Scheduled Tasks Programmatically)
** Bonus Tipp: In order to avoid a taskkill java.exe command killing your remote agent, you can simply rename the java.exe of your jvm to jenkins_remote_agent.exe and use that as your jenkins remote agent executable
UFT requires an interactive session for some Win32 operations.
In the Tools ⇨ Options menu, select General ⇨ Run Sessions there you will find an option to Enable continued testing on locked/disconnected remote computers, this may help in your case too.
I'm running a java test suite on a windows jenkins agent with gradle
When it's running, the jenkins master is reporting this
Starting a Gradle Daemon, 84 busy and 2 stopped Daemons could not be reused, use --status for details
Here's the command it's running
cmd.exe /C "C:\development\jenkins\apppath\gradlew.bat -DenvName=testserver -DenvDriver=ie -PenvName=testserver -PenvDriver=ie regression && exit %%ERRORLEVEL%%"
The number of busy gradle daemons keeps increasing, and I think is affecting the performance of the tests, they keep taking longer and longer.
If I go onto the windows slave and run
C:\development\jenkins\apppath\gradlew.bat --status
It shows as 0 gradle daemons running or busy.
I need to be able to stop all those busy daemons.
Anyone got any ideas how to achieve this?
I've tried restarting the jenkins agent and the master, to no avail.
I've also tried running the following command on the windows agent, still no luck
WMIC PROCESS where "Name like 'java%' AND CommandLine like '%GradleDaemon%'" Call Terminate
I am trying to run some automated acceptance tests on a windows VM but am running into some problems.
Here is what I want, a job which runs on a freshly reverted VM all the time. This job will get an MSI installer from an upstream job, install it, and then run some automated tests on it, in this case using robotframework (but that doesn't really matter in this case)
I have setup the slave in the vSphere plugin to only have one executor and to disconnect after one execution. On disconnect is shutsdown and reverts. My hope was this meant that it would run one Jenkins job and then revert, the next job would get a fresh snapshot, and so would the next and so on.
The problem is if a job is in queue waiting for the VM slave, as soon as the first job finishes the next one starts, before the VM has shutdown and reverted. The signal to shutdown and revert has however been sent, so the next job is almost immedieatly failed as the VM shuts down.
Everything works fine as long as jobs needing the VM aren't queued while another is running, but if they are I run into this problem.
Can anyone suggest a way to fix this?
Am I better off using vSphere build steps rather than setting up a build slave in this fashion, if so how exactly do I go about getting the same workflow to work using buildsteps and (i assume) pipelined builds.
Thanks
You can set a 'Quiet period' - it's in Advanced Project Options when you create a build. You should set it at the parent job, and this is the time to wait before executing the dependent job
If you'll increase the wait time, the server will go down before the second job starts...
Turns out the version of the vSphere plugin I was using was outdated, this bug problem is fixed in the newer version
I was using the Restart Safely option in jenkins to restart the master after some running jobs completed.
However jenkins was unattended after that and now it's up and running. Is there a way to check when the master restarted in the form of jenkins reboot history (or something like ps -ef equivalent would also work in that I can see the process start time to get details of the restart).
It will be in /var/log/jenkins/jenkins.log.log.
Check for Jenkins is fully up and running you should also see messages about the scheduled reboot.
I have a jenkins job that runs a bash script.
In the bash script I perform effectively two actions, something like
java ApplicationA &
PID_A=$!
java ApplicationB
kill $PID_A
but if the job is manually aborted, the ApplicationA remains alive (as can be seen with a ps -ef on the node machine). I cannot use trapping and so on, because that won't work if jenkins sends a 9 signal (trapping doesn't work for 9).
It would be ideal if this job could be configured to simply kill all processes that it spawns, how can I do that?
Actually, by default, Jenkins has a feature called ProcessTreeKiller which is responsible to make sure there are no processes left running after the job execution.
The link above explain how to disable that feature. Are you sure you don't have that disabled by mistake somehow?
Edit:
Following the comments by the author, based on the information about disabling ProcessTreeKiller, to achieve the inverse one must set the environment variable BUILD_ID to the build id of Jenkins job. This way, when ProcessTreeKiller looks through the running processes to kill, it will find this as well
export BUILD_ID=$BUILD_ID
You can also use the Build Result Trigger plugin, configure a second job to clean up your applications, and configure it to monitor the first job for ABORTED state as a trigger.