I usually got the job id with:
MY_CONDOR_JOB_ID
but I don't see it set if it's an interactive job. Is there a way to set it? When I am given the resources I see that there is a job id for my job. Is there a way to get it?
Here is what it should be
Submitting job(s).
1 job(s) submitted to cluster 4869.
Waiting for job to start...
HTCondor proper doesn't set MY_CONDOR_JOB_ID, so either your submit file or your administrator has set this up.
If your submit file contains
environment = CONDOR_JOB_ID=$(Cluster)
Then HTCondor will insert the job cluster id into the environment variable CONDOR_JOB_ID. To get this into a condor_submit -i, you'll need to pass the name of this submit file to condor_submit. So, try putting that into a submit file, maybe named env.sub, and run
condor_submit -i env.sub
Or, if you already have a submit file which sets this, pass the name of that submit file to condor_submit -i
Related
I have created some global credentials in Jenkins, and I want to pass them to a powershell command that starts the execution of a protractor test suite.
The credentials are created properly, the bindings are also done as you can see int he image below:
The thing is, I need these credentials to use them when running the automation tests. The powershell command that I execute is the next one:
npm run test -- --userName=${env:ECASUSER} --password=${env:ECASPWD}
After I start the job the command is called inside the windows agent as expected, triggering the tests. When the test are using those credentials to authenticate it seems they are empty strings.
In the job console log, both credentials appear to be there but displayed like this (****).
I have tried a lot of solution none of them work. Am I doing something wrong here?
After some time spent to this, I reached the conclusion that this never worked. Or maybe it did at some point but, yeah it simply stopped.
Basically, Jenkins is not passing credentials to Windows batch or Power shell commands. My automation tests were running on blanks.
The only solution, that I found to this problem, is this one:
Create a new binding: Username and Password(conjoined) - here create a new job parameter containing the credentials. Let's say the parameter is named USERPASS;
Create a new 'Windows batch command' section where you save the credentials to a file in you test project (amazingly this one works) - your credentials will be saved to the file like this: "username:password". This is how you save the credentials:
echo %USERPASS% > "%WORKSPACE%\password.txt"
Change the automation test project to retrieve the credentials from the file;
Delete the file after the tests are completed.
I believe it should have been
npm run test --userName=${ECASUSER} --password=${ECASPWD}
and make sure you don't pass unnecessary --
Let me know if that doesn't work, I have other ideas
I have a perlscript file was running fine in crontab but suddenly it stopped running without any modification.
cd /home/user/public_html/crons && ./script.pl 2>&1 >/dev/null
The top of the script file is #!/usr/bin/perl -X
The output expect from this script is changes in database
I have another script file with the same modification and still works fine
When I run the file in the browser it works fine and execute all lines without any problem
I tried full path /usr/bin/perl but it didn't work
I tried Perl at the beginning but it didn't work
I run the command from SSH using putty but nothing happened
I checked log file /var/log/cron but no errors at all
I created temporary log file cd /home/user/public_html/crons/script.pl> /tmp/temp.log 2>&1 to see the errors but the log is empty
Here is the solution:-
I found the issue, There is was a stuck process for the same cron file , so i killed this process and its fixed
You can find your file process like this
ps aux | grep 'your cron file here'
This is a really common antipattern people seem to tend toward with cron.
Cron sends you an email with the output of your script, if it generates any output. People often redirect output to /dev/null to prevent cron from sending the email. This is bad because now the output of your script is lost entirely. Even if the script has some built-in logging, it might generate errors before it gets the log file opened and those are lost. It also might crash in a way that doesn't get written to the logging mechanism.
At a bare minimum, you should just remove 2>&1 >/dev/null to start receiving the email. (and also, test your mail setup using a temporary cron job like 1 * * * * echo "Test" )
The next better solution is to change it to >> /var/log/myscript/current.log and then also set up something to rotate the log files (like logrotate) and also make sure to create that directory with permissions that the script user is allowed to write to it. By only redirecting STDOUT of the script, any errors or warnings it writes to STDERR cause you to get an email, and if there are no errors/warnings the output goes to the log file and no email gets sent.
Neither of those changes solve the root problem though, which is that when cron runs your script it does so with a different environment than you have on the command line. What you really want is a way to run the script with a consistent environment, and log it. The "ultimate solution" is to define your task in some kind of service manager, and then use cron to occasionally start it. For instance, you could use systemd and define a service that doesn't restart, then use systemctl start my_custom.service in your cron job. Now you can test independent of cron, and your tests will have the same exact environment, and be logged by the service manager. As extra bonuses, you are protected from accidentally running your script twice at once, and you get a clean way to stop a running cron job without the danger of stale pid files.
I don't particularly advocate systemd myself, but thankfully there are lots of alternatives:
Runit : http://smarden.org/runit/runsvdir.8.html
S6 : https://skarnet.org/software/s6/
Perp : http://b0llix.net/perp/site.cgi?page=perpd.8
(but installing and configuring a service manager is a bigger task than just using systemd if your distro is based on systemd) Each of these allows you to define a service that doesn't restart. Then you use a shell command to issue a "run once" directive to the supervisor, which runs the task as a child. Now you can easily launch the jobs yourself and see all the errors in the log, and then add that command to the crontab and know that it will run identically when cron starts it.
Back to your original problem, once you get some logging you are likely to discover it is a permission problem or a upgraded module in the system perl.
You know how, with a Rundeck job, when you define an launch command script, you can reference job run option variables with things like #option_var_1#. Is there a symbol like this that evaluates to the number of the job run? I'd like to pass that value to my executable as a command-line variable.
I assume you are looking for the execution id of the job.
job.execid: ID of the current Execution
I have a scheduled job on rundeck (2.6.2).
This jobs run a script that needs an node environment variable available (like $HOME, $USER or $PWD. A custom one. ) for all user in the node/nodes.
I could use jobs options to solve this if I wanted trigger the job from API ( Or manually. Rundeck ask me for the option ) but is a scheduled job. I can't use Options -> Default Value because the jobs could run in nodes with different values for this environment variable.
There is any way to offers all / some node environment variables to rundeck to be used inside the scheduled jobs?
(I have thought in use Options -> Allowed Values -> Remote URL but is a mess. Too complicated to me requirement)
Thanks.
The easy way in my case has been to customize /etc/rundeck/profile adding into it all the stuff I wanted.
Seems a pretty good solution to me.
I succeeded to perform this by adding the following lines:
set -a
. /etc/environment
. /etc/profile
1) put those lines into the file: /etc/rundeck/profile
2) put those lines into a script step
Remark: I'm using only script steps in my rundeck and I'm always put this lines in the first line of the script step:
#!/usr/bin/env bash
when I doing a calculation halfway, I just found the runtime limit 50:00 may not be sufficient. So I use $bstop 1234 to stop the job 1234 and try to modify the old runtime -W 50:00 to -W 100:00
Can you suggest a command to do so?
I tried
$ bmod -W 100:00 1234
Please request for a minimum of 32 cores!
For more information, please contact XXX#XXX.
Request aborted by esub. Job not modified.
$ bmod [-W 100:00| -Wn ] 1234
-bash: -Wn]: command not found
100:00[8217]: Illegal job ID.
. Job not modified.
according to
[-W [hour:]minute[/host_name | /host_model] | -Wn]
from http://www.cisl.ucar.edu/docs/LSF/7.0.3/command_reference/bmod.cmdref.html
I don't quite understand the syntax, -Wn does it mean Wall time new
Many thanks for your help!
The first command fails because LSF calls a the mandatory esub defined by your administrator to do some preprocessing on the command line, and this is returning an error. Here's the relevant quote from the page you linked:
Like bsub, bmod calls the master esub (mesub), which invokes any
mandatory esub executables configured by an LSF administrator, and any
executable named esub (without .application) if it exists in
LSF_SERVERDIR.
You're going to have to come up with a bmod command line that passes the esub checks, but that might cause other problems because some parameters (like -n I believe) can't be changed at runtime by default so bmod will reject the request if you specify it.
The -Wn option is used to remove the run limit from the job entirely rather than change it to a different value.