I have an ansible playbook that calls a Terraform deployment, then provisions the deployment with another ansible call,
This gets to a certain point and hangs with limited output to the console... This will hang for a long time without knowing what is causing it to hang. Even when I invoke a -vvv or -vvvv flag
Is there anything I can do to enable a debug output to console to pinpoint what is causing the hang?
I presume the commands ran during the provision are not getting an exit 0 somehow.
Related
I am using Azure Devops pipeline and in that there is one task that will create KVM guest VM and once VM is created through packer inside the host it will run a bash script to check the status of services running inside the guest VM.
If any services are not running or thrown error then this bash script will exit with code 3 as i have added the value in bash script as below
set -e
So i want the task to fail if the above bash script fails, but issue is in the same task as KVM guest VM is getting created so while booting up and shutdown it throws expected errors but i dont want this task to fail due these error but to fail it only bash scripts fails.
i have selected the option in task "Fail on Standard Error"
But not sure how we can fail the task specifically for bash script error, can anyone have some suggestions on this?
You can try and use exit 1 command to have the bash task failed. And it is often a command you'll issue soon after an error is logged.
Additionally, you also may use logging commands to customized a error message. Kindly refer to the sample below.
#!/bin/bash
echo "##vso[task.logissue type=error]Something went very wrong."
exit 1
My ansible playbook consist several task in it and I am running my ansible playbook on Virtual Machine. I am using ssh method to log in to VM and run the playbook. if my ssh window gets closed during the execution of any task, would my ansible script be still going on and perform the rest of the task in the play ? or will it stop as the ssh window already got closed ?
Thanks in advance.
The playbook stops running. You need to keep the window open (or use something like screen) if you want it to finish after you close the window.
I have a playbook, as below:
tasks:
- name: Execute a program_A on managed node
win_command: 'D:test\program_A.exe'
I run this playbook but hung and no any response on managed node (Windows 2012). (i.e. there is a program_A.exe process generated on managed node but no response, it's CPU usage time is always 0%)
I also tired to replace win_command by win_shell module, raw module, but it still hung and no response on managed node...
When I try to open a command window on the managed node to run D:\test\program_A.exe directly, the program_A.exe was successfully executed.
What could be wrong?
Make sure the exe file is executed by the same privilege. eg. when you directly execute it, you are using Administrator, but in playbook, you may use guest rule.
I am trying to become a Jenkins user through this command - sudo su -s /bin/bash jenkins.
When I do run it, this happens in my shell: bash-4.2$ Killed.
I have been trying to debug it by identifying the memory allocation used on the server (we have plenty), reading debug lines of processes being killed, and the jenkins log but there's nothing that leads me towards a solution.
How do I start to debug this problem and what could be going on? There aren't any obvious errors being thrown my way.
I've discovered that when I restart the server, I can log in as the jenkins user and the jenkins builds work. However, shortly thereafter, I cannot log in and the builds no longer work.
I have a complex script - that Jenkins executes on build - which needs to check for events in /var/log/syslog. In order to do so, I added the user "jenkins" to the group syslog belongs to and set the file permissions to 0640.
The script above runs perfectly fine when manually executed, but when invoked by Jenkins build system it fails: indeed, the output console shows that the script has not the permission to read /var/log/syslog when invoked via Jenkins.
A quick check with whoami shows that the building process runs with "jenkins" as user, though. Hence, I cannot understand why the script behavior is different.
I haven't used jenkins, so this might not be what's going on, but do you know if you are running under SELinux or any other sort of mandatory-access-control system?
That tends to be my knee-jerk reaction to strange permissions issues.
If SELinux is enabled, try checking /var/log/audit/audit.log to see if there are any denials to read /var/log/syslog.
If you are on Linux, the command "getenforce" should tell you whether SELinux is running or not.