I'm configuring our CI infrastructure and when project loading fails sbt asks what to do:
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
This hangs the build which waits for process to return.
Is there a way to tell sbt to stop without asking what to do when loading fails?
Invoke SBT with the -batch option. It will still print the prompt but not actually wait for a reply, instead it will exit with a non-0 status.
IMHO patching the sbt launcher, so the sbt executable, is acceptable only if it has to be done once, ie on a single CI box or on your devenv.
Instead as a trick you can close the stdin on the sbt command:
sbt < /dev/null
and by doing so interactive mode will not be enabled, causing it to exit in case of errors.
See here for a rather similar question.
Disable the underlying JLine terminal type via a JVM argument
-Djline.terminal=off
and SBT will be unable to prompt you, and simply exit.
Related
Getting below error while trying to run shell script
+ /home/pqsharma/symlinkBuild.sh 19.07
sh: line 1: 21887 Terminated sleep 3
With Jenkinsfile:
node ('linux')
{
stage('creating symlink')
{stdout = sh(script:'/home/pqsharma/symlinkBuild.sh 19.07 ', returnStdout: true)
}
}
This is followed by JENKINS 55308: "intermittent "terminated" messages using sh in Pipelines"
Jenkins master runs from a Docker image based on jenkins/jenkins:2.138.2-alpine with specific plugins baked into the image by /usr/local/bin/install-plugins.sh
The message originates in durable-task-plugin, which must be a dependency of one of the plugins.txt plugins.
Check if this is the case for you.
Caused by JENKINS 55867: "sh step termination is never detected if the wrapper process is killed"
When you execute a shell step, Jenkins runs a wrapper shell process that's responsible for saving the exit code of your script. If this process is killed, then Jenkins never discovers that your script has terminated, and the step hangs forever.
This seems to have been introduced after v1.22 of durable-task-plugin
Diagnostic:
The sleep 3 is part of the execution of a shell step.
A background process touches a specific file on the agent every 3 seconds, and the Jenkins master checks the timestamp on that file as a proxy to know whether the script is still running or not.
It seems based on the reports here that something is causing that process to be killed on some systems, but I don't have any ideas about what it could be offhand.
Possible cause:
The bug is not just in the durable-task-plugin, although the symptoms come from there. It is introduced when you upgrade workflow-job. I have managed to pinpoint it down to a specific version.
Upgrading workflow-job to 2.27 or later triggers the bug. (2.26 does not exist.)
So try and downgrade your workflow-job plugin to 2.25
I'm running a Thorntail 2.2.1.Final microservice with Maven using either of these commands
mvn thorntail:start
mvn thorntail:run
It runs fine, but when I hit Ctrl-C it doesn't exit the application i.e. the console returns, but the app runs in the background. I've tried to stop it
mvn thorntail:stop
But that doesn't work. I have to go and kill the process. I'm using Windows 10.
The thorntail:start and thorntail:stop goals are meant to be used together as part of a Maven lifecycle, typically for integration testing. That is, thorntail:start intentionally leaves the process running in the background, and thorntail:stop should stop it.
For interactive use, mvn thorntail:run should be used. That keeps waiting in the foreground, and Ctrl+C should stop the application behind it.
If none of that works, it's a bug. I'd recommend filing a bug in https://issues.jboss.org/browse/THORN and preferrably also include a jstack output for the process.
I am running Eclipse, version 3.6.1 on RHEL 6.7
I have created two breakpoint actions, one is an external tool -> shell script and the other is a simple log action.
The log action seems to work flawlessly and when the breakpoint occurs, everything happens as expected.
On the other handle, when the breakpoint occurs, the shell script fails with the following:
As a side note, the shell script can run by itself as an external tool, but fails when attached to a breakpoint.
Suggestions???
This was resolved by migrating my workspace from Helios-3.6.1 to Mars-4.5.0.
I need to create a Jenkins job that runs a PowerShell script on another server over SSH.
I am using 'Send files or execute commands over SSH' option to do the needful. The 'Exec command' field has value "cmd /c XCopy.bat" where XCopy.bat (batch file present on the other server - Windows server 2008 R2 - where my SSH is installed) in turns runs the PowerShell. The job is simply to copy a folder and its content to another location.
When I build the job, the copying is done as desired. However, the job terminates in Unstable build. Here are the logs:
SSH: Connecting from host [USVAUJNKW001]
SSH: Connecting with configuration [54.254.146.206-SGSGDAPPW001] ...
SSH: EXEC: STDOUT/STDERR from command [cmd /c XCopy.bat] ...
**copy job done**
SSH: Disconnecting configuration [54.254.146.206-SGSGDAPPW001] ...
ERROR: Exception when publishing, exception message [Exec timed out or was interrupted after 120,012 ms]
Build step 'Send files or execute commands over SSH' changed build result to UNSTABLE
Finished: UNSTABLE
I have tried different 'Exec timeout (ms)' values and (un)checked 'Exec in pty' but to no success.
Queries:
Is there any other option in Jenkins through which I can accomplish the task i.e. to simply run a PS script on another server via SSH.
How could I be using the current option incorrectly?
Do I need to make changes, if any, at batch/PS file level to return some code that tells the Jenkins that job is complete and it should exit successfully?
I have tried to find answers on different forums but none has been exactly useful.
This issue can be resolved by changing the Job configuration.
When using Send Files or execute commands over SSH
Click on Advanced Tab.
Set Execution Timeout(ms): 0
This will help you in avoiding the timeout exception. It has worked for me, so hopefully it will work for you too.
Increase the timeout of SSH server configured in Manage Jenkins settings. Also the exec timeout in job configuration.
relate to Jenkins Text-finder unable to success my Build
Into your job's configure page
Roll down and In Post Steps SSH Publishers
In Transfers Set, click advanced
checked Exec in pty
rojo's suggestion of redirecting output worked for me. I appended this to my script:
>> /var/log/[project-name].log 2>&1
I am new to Hudson with PSEXEC, i am using hudson in my computer, i want to run batch file on remote computer from hudson build.
I used PSEXEC to run batch file on remote computer,when i executed from command promt it working successfully.But same i did from Hudson build its hanging..it's not doing anything.so please give any suggestions is there any other way we can handle this.
I want to do this quikly...urgent
Anyones help is appreciable
thanks in advance.
Could it be that psexec is waiting for a user entry? In this case hudson will hang.
Does Hudson runs with your user credentials? if not lunch a command Prompt with the credentials Hudson is running with and see what happens if you call psexec. If hudson runs on the local system account, you can't start a command prompt with it. Than try to run Hudson with your credentials and see what happens.
BTW, did you check Hudsons log files (just in case that there might be something)?
I had the same problem where PSEXEC simply hung.
The solution i found (after trawling for AGES) was to add the parameter -accepteula to the PSEXEC called. Hudson stopped hanging after that.
Very frustrating.
maybe it is too late, but I thought I will post it for others who have the same problem.
Psexec has problem running from any CI server, doesn't matter what CI server you have, is it Hudson, Teamcity, ...).
Psexec hangs when run from the build server.
It doesn't hang for all commands, but with some commands , psexec will hang.
The problem resides with how psexec will read the output of the remote running command.
The ultimate solution is to use other tools than psexec.
You can check this blog of this solution.
But if you need a simpler solution, and you don't care about the output of the command, I came up with a simple solution that suppress the output of the psexec.
You can write a small c# program that will run the psexec command, suppressing its output.
I blogged about that here
I thought I would respond to this since I was having the same hanging problem with TeamCity and psExec. Since I believe it is actually an issue with Java executing psexec, it should apply in the case of Hudson as well.
While I ran into the accepteula issue was early on, you only need to agree once and it sets a registry setting. As user327759 indicates the -accepteula switch in the script would cover your basis the first time and for ever after.
If this doesn't fix your problem, which it didn't in my case, you need to add the "-i" command switch. ex: psexec -i \ServerName "C:\folder\file.bat"
For context regarding this solution, I have included my backstory:
I was able to execute this PsExec command just fine via a MsBuild task, via a .Net wrapper and via straight command prompt usage, but TeamCity would just hang on the execution. It seems that Java is expecting some response on standard in, when it invokes the psexec exe. On the remote server I would see the psexecsvc process fire up and register in the services console appropriately, but then it would stop. After reading many posts such as this one, and struggling for far longer than I would care to admit, I eventually tried -i option, despite not needing this in any other execution scenario outside of TeamCity. The psexec documentation indicates that -i will "Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session." It is still unclear to me why this makes all the difference for TeamCity.