Presently we are facing build failure problem in Travis because of https://github.com/travis-ci/travis-ci/issues/7702. I was just wondering if Travis has any command line option to kill it with exit code 0, then I can force travis to terminate 'after_success'. Will be a hacky way to deal with this situation until they solve this bug.
The shell function travis_terminate will help.
Alternatively, you can ensure to do set +e before the call to exit.
travis_terminate 0 is the best solution at the moment.
Related
I have pods that are of kind Cronjob running in parallel. They complete task and run again after fixed interval of 20 minutes as per cron expression. I noticed that some pods are restarting 2-3 times before completing task.
I checked details in kubectl describe pod command and found that pod exit code 2 when it restart due to some error:
Last State: Terminated
Reason: Error
Exit Code: 2
I searched about exit code 2 and found that it is misuse of a shell builtin commands. How I can find which shell builtin is misused. How to debug cause of exit code 2.
Thanks in advance.
An exit code of 2 indicates either that the application chose to return that error code, or (by convention) there was a misuse of a shell built-in. Check your pod’s command specification to ensure that the command is correct. If you think it is correct, try running the image locally with a shell and run the command directly.
Refer to this link for more information.
You can get logs with
kubectl logs my-pod
Post output here if you can't fix it.
I received this error message which means something is erroring inside a bash script executed by the Dockerfile.
As an example, if something inside test.sh errors:
RUN test.sh
# 16 ERROR: executor failed running [/bin/sh -c test.sh]: exit code: 127
Question
What is the recommended way to gain visibility over the exact error message (i.e. to find out what's gone wrong) and to diagnose which line(s) of a bash script executed from a Dockerfile are problematic? Can docker be made to provide the output of the bash script so the exact error message is provided? Rather than just the somewhat cryptic:
executor failed running exit code: 127
as seen here.
What I know so far
One way to diagnose which line(s) is playing up is to survey the script, assess which line(s) might be causing problems, and comment out the suspect line and everything after it. If the error goes away, you've found the (first) line that is a problem, and it can be addressed. Rinse and repeat until the script is error-free. But this seems more manual than one would hope.
I've tried to search for this but i couldn't fine anything. I have a Nolio flow that has a command line action to deploy a solution with psake. The command line is run like this:
psake.cmd .\deploy.ps1 -parameters #{env='Environment'} if ($psake.build_success -eq $false) { exit 1 } else { exit 0 }
But if the script deploy.ps1 fails the nolio deployments hangs and need to be stopped manually.
Is there a way to make the deployment stop automatically when the script fails?
I found a solution for this. Nolio offers an action called "ROC - Fail Deployment Step". I achieved what i wanted by deselecting the pause on failure and adding this action after the script execution and setting the operation on link to "On failed"
Sometimes it happens that a fastlane action throws an error like:
ERROR [2016-11-06 03:34:20.16]: Shell command exited with exit status 48 instead of 0.
I found troubleshooting difficult, as --verbose is not not verbose enough. By action I don't mean sh action, which is rather special case, but other fastlane actions e.g. create_keychain. The action create_keychain calls shell command security create-keychain and when it fails there is no clue what happened.
How do I find output of a shell command run by fastlane's action?
How do I find what shell command including all parameters is fastlane actually trying to run?
The output of the shell command is printed out by default when you use the sh action. Alternatively you can also run the shell command directly yourself using backticks (standard Ruby)
puts `ls`
The answer is that there is no such option at the moment, but it should be easy to add it.
I have created git issue #6878 for it.
I would check the uwsgi config before restarting it, because if it is not valid, it should give warning and does not restart.
1) Can i solve this with writing some kind of plugin or using hook?
I've found a phase (as-user-atexit) to which i can attach a hook (exec some kind of shell commands), but i don't see how can i prevent restarting.
2) Or should i solved this on level overwriting systemd unit script?
you may want to check this http://uwsgi-docs.readthedocs.io/en/latest/FallbackConfig.html for an alternative approach