I am using Linux Centos to schedule a job.
I have created a shell script file called Im_daily_loads.sh to run the job at 12:42PM everyday.
with the following comands:
#!/bin/sh
42 12 * * * cd $pdi; ./kitchen.sh -file="/opt/kff/software/pdi/5.0.1.A/data- integration/projects/IML/code/stg/IML_Load_Frm_SRC_To_PSA.kjb" -level=Basic > -logfile="/opt/kff/software/pdi/5.0.1.A/data-integration/projects/IML/log/iml_daily_loads.err.log"
Then loaded the file into crontab by using the issuing the following command crontab Im_daily_loads.sh, but my job is not running.
What would be the problem?
Why not just use
crontab -e
as the user you plan to execute the job as, enter the job, save and exit the editor?
Also, it looks like you need to define $pdi in your script. How is crontab supposed to know where your script is located?
first , run a very simple job to be shure crontab works at all.
for example
set > /tmp/crontab_works.log 2>&1
it will write down all variables. so you will see not all variables available in crontab
Related
I want to run the below via Crontab job and not working but when put them in sh file and run the sh manually it works fine.
Sh file path: /opt/etc/rt4/test.sh and the content as below:
wsgetmail --config=account01.json
wsgetmail --config=account02.json
Running manually:
sh /opt/etc/rt4/test.sh it works fine.
Crontab:
*/1 * * * * /opt/etc/rt4/test.sh
Crontab runs this file but those commands are not working.
I have other Crontab jobs and they are working fine as intended.
The crontab and terminal are two different environments, the wsgetmail perl module command is recognizable for terminal but to make it recognizable for corntab we have to add the full path to the module (wsgetmail) in the shell script.
in this case test.sh should looks like this:
#!/bin/bash
/usr/local/bin/wsgetmail --config=account01.json
/usr/local/bin/wsgetmail --config=account02.json
Running manually: sh /opt/etc/rt4/test.sh it works fine.
Crontab: */1 * * * * /opt/etc/rt4/test.sh
Those are not the same thing, as 1st line shebang, and chmod a+x test.sh, will affect the behavior.
Either remove "sh" when running manually, or prepend it to the cron command.
Run $ id, and determine if that's different
from how the cron command runs, perhaps by
having cron log id output.
Running as yourself manually,
versus as root (uid=0) under cron,
can change the behavior of that command.
Numerous other things are different
under cron, such as lack of a pty.
Take a look at $ env | sort manually.
Then run it under crond, and note the huge difference.
Pay special attention to PATH.
It is likely to be much shorter under cron,
and that can lead to "command not found"
diagnostics.
But you chose not to share any diagnostic
error messages with us,
so coming up with a definitive diagnosis
of this amounts to a mind reading exercise.
I've created the file crontester on /etc/cron.d with this line on it:
* * * * * /usr/bin/flock -n /tmp/fcj.lockfile touch /tmp/test.txt
That should be running every minute.
But I dont see the /tmp/test.txt file being created, so the cron is not working correctly.
What I'm doing wrong? Do I've to create the /tmp/fcj.lockfile, if I've to do this, do I have to create it empty?
Thanks a lot.
The command runs fine on my machine, so the cronjob is probably not set up properly. man cron discourages creating /etc/cron.d/ files:
Like /etc/crontab, the files in the /etc/cron.d directory are monitored for changes. In general, the system administrator should not use /etc/cron.d/, but use the standard system crontab /etc/crontab.
Try creating the cronjob using crontab -e and see if it works
I'm trying to start a bash script(test.sh) from a second bash script that runs as a cronjob(startTest.sh) on Ubuntu 14.04.
Cron is running and both scripts work perfectly if called from command line.
startTest.sh looks like this:
#!bin/bash
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/home/username/path/to/script
bash /home/username/path/to/script/test.sh
test.sh looks like this:
#!/bin/bash
touch it_works.txt
My crontab entry looks like this
* * * * * /usr/local/bin/startTest.sh
Best practice is generally not to use relative paths (unless you do an explicit cd) in scripts run as cron jobs.
crond is probably not running from whatever directory you expect it to. Depending on what user this cron job runs as, the script either does not have permission to create it_works.txt in crond's current working directory, or it is creating the file and you're looking in the wrong place.
I have a shell script that I have scheduled using cron using a command:
0 10 * * * /directory/Script.sh > /directory/log/output.log
The script is scheduled to run at 10 AM everyday. The script executes but produces output files only with headers, no content is there.
The script produces two output files. When I run the script manually it works fine. But when scheduled it is not producing the correct output.
Help me out.
Thanks
Multiple reasons
1> Check full path of all executable in the script.
2> Ensure all environment variables are set accordingly
3> Check the script when run from the same user as the cron is executing.
Technically there is no difference between manually running a script and scheduling from cron
I made a shell script and registered to execute every 20 minutes.
Here is my crontab code.
*/20 * * * * sh /mypath/run_myprocess.sh &> /dev/pts/34
I editted code like this in order to see whether my process run correctly.
I get the result '/dev/pts/34' from tty command in terminal.
However, does anyone know how to use linux command results(in this case: /dev/pts/34)
in crontab? This is because I will use several terminal to run my tasks.
For example, in shell script, I can use linux command result in the form of $(command) such as
echo "$(date)"
directly.
Plus, if I type something on the terminal during process running with crontab, it actually gives result. For example,
Process is running........
ls
backup backup.sh Desktop Task_Folder shared_folder
[UserID] ~ #
So I guess cron jobs run correctly but in background.
Please help me to find out how can I bring cron jobs in foreground.
If you start a job on your console and background it you can then bring it to foreground. If the task is not yours or not started on your terminal then you can not.