I'm trying to set timeout on workflow run in oozie, which fails after some time from start of workflow run.
For example, one can use sla:should-end within coordinator.xml for action/workflow, or specify sla:should-end within workflow.xml for entire workflow.
But the problem is SLA only sends email. What I want is just fail after some time (from start of run).
Is it possible? Any sample code would help.
I don't know of any straight solution for this in Oozie or in Yarn. There is a Yarn ticket that would provide a convenient solution.
Until it's implemented you can try something like this:
add a FS touchz action to the beginning of the workflow to create a file ( e.g. /tmp/WF_ID )
add a fork to the workflow after the file is created
one of the paths should be a shell action that checks for the existence of the file with hdfs dfs -ls /tmp/WF_ID until a timeout is reached ( see this post for some hints )
the other path is the original workflow logic and an FS delete action at the end to delete the file in /tmp
the shell action should kill the workflow if it times out before the file is deleted from HDFS. If the file is deleted before the timeout is reached, the shell script should terminate normally, letting the workflow to continue
This is quite an ugly workaround of the problem, but I can't think of a cleaner solution at the moment.
Related
I have been monitoring the Complete learning plans which are due task, which is set to run every minute. I have set the cron.php script with a password to force the cron job to run. When I reload the page I notice that the cron job runs, sets the next run date time, but doesn't run again and changes to ASAP.
I am using Moodle 3.6.3 on Windows IIS.
Create a task in task scheduler to execute the script after every minute (or any time you want). Use "Start a program" action. Replace "C:\Program Files\PHP\v7.2\php-win.exe" with your php version and also change the moodle path to yours.
I have an autosys job which logs into a windows machine and performs some tasks and logs all the working into a word file on the machine.
For yesterday's run, it failed because the file in which it logs was left open by some user who logged into the machine to check the logs. The job failed because the word document(my log file that is) always opened in Edit mode only. is there a way to restrict anyone from making changes to the log file except the automated autosys job?
No, but you can add on the job log creation %autorun% which will then create a new log everytime the job runs.
In Informatica we have mapping source qualifiers connecting to Amazon Web Services—AWS.
We often and erratically get a failure that our s3 bucket names do not comply with naming standards. We restart the workflows again and they continue on every time successfully.
Is there a way to trap for this specifically and then maybe call a command object to restart the workflow command via PMCMD?
How are you starting the workflows in regular runs?
If you are using a shell script, you can add a logic to restart if you see a particular error. I have created a script a while ago to restart workflows for a particular error.
In a nut shell it works like this
start workflow (with pmcmd)
#in case of an error
check repository db and get the error
if the error is specific to s3 bucket name
restart the workflow
Well... It's possible for example to have workflow one (W1):
your_session --> cmd_touch_file_if_session_failed
and another workflow (W2), running continuously:
event_wait_for_W1_file --> pmcmd_restart_W1 --> delete_watch_file
Although it would be a lot better to nail down the cause for your failures and get it resolved.
In VSTS release management there is a nice remote Powershell task where we can run a script on the target machine. However I'd need a way to tell the release managment that only run this file if it exists, otherwise silently ignore that.
I know I can configure a task to not block the process in case of error, however in that case there still will be an exclamation mark in the log and the deployment will get the partial succeeded status. I'd like to avoid this and show success even if the file doesn't exist.
With this I need it to support kind of optional setup scripts for several deployed products.
There isn’t the setting or feature in VSTS to check whether the script file is existing or not.
The simple way is that, you can create another script to call target script.
Create another script (e.g. wapperScript.ps1) to call target script (can use parameter to accept the target script path) and add to source control
Add Windows Machine copy task to copy wapperScript.ps1 to target machine
Add Remote PowerShell task to run wapperScript.ps1
If you make your script more robust with a guard clause so that it can be called regardless of any given environmental condition. This keeps your pipeline less complicated. You can take action on the "file exists" leg and do a noop on the other. You can signal to the release process either way with log entries.
I am working on a perl script which will do the following:
Trigger a script in post build action when job fails.
Read the log file and try to match the errors with a consolidated error/solution file.
If error is matched with pattern file, then concatenate the error message with the solution at the end of log file.
I am facing following challenges:
All jobs are running in Slave but the error log file is stored in Master. How can I run the script in post-build action? The script path will be taken from slave but my script is located in master. Is there any workaround for this?
The path of the error log is - /home/jenkins/data/jobs//builds/BUILD_NUMBER/log
We have many jobs that have folders created by jenkins folder plugins…how do we set the common folder for these?
/home/jenkins/data/jobs/FOLDERX//builds/BUILD_NUMBER/log
Other questions -
Do you think that publishing the jenkins error log and displaying the solution is the right approach?
There is no information on how complex the pattern maching is, but if it is a simple line based regex match there is a plugin for that, called Build Failure Analyzer.