Shell Programming and Scripting

That's correct, because your script not able to find the below cmd
ec2-describe-instances --> What is this cmd for?
I think you have to call it with full path... or you may have to define it in your script and call.

When I've come up with a different behaviour in script vs. cronjob execution, it has turned out to be probably because of one these (presuming you are in the same machine):

- user executing the cron task is different from the one used for testing.
- user is the same for cron and testing BUT it's using different environments.

Logging with "su" instead of "su -" it does not load the user's environment. So when running cron, the system executes the script loading the user's environment, of course. Then if testing when same user but different environment, there are many chances that the script is not going to behave in the same way or in the way expected.

Alternatevely, you may have logged in using a non-interactive shell like ssh to test the script, and then the script run using the local environment.

So how do you log in in the system when testing the script?

K.

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

The script is working fine now using cron

Seem like you are not using the full command path. You must reference the "ec2-describe-instances" command to where you installed your ec2 cli like

/location/to/folder/ec2-describe-instances

Are you creating the crontab under the same user account as you have test the shell script manually?
SetCron
setcron.com

command not found means an executable file for the command (ec2-describe-instances) was not found in any of the directories listed in PATH.

Common mistake. Job submitted by cron do not inherit any environment. It is the responsibility of the submitted script to guarantee all necessary environment variables are set. That's why it executes fine when you submit it from a command line. When you logged on, your session had a lot of environment variables (including PATH) set, mostly from your .bash_profile (or .profile). When you submitted the script from the command line, that process inherited your environment.