Running `wsgetmail` service via Crontab job CentOS 6

Question

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.

Answer 1

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

Answer 2

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.