hi i have a script in my crontab it was working and all of a sudden it stopped working and i have run the script from the CLI and it works fine does anyone have any idea what can cause this.

Does the script rely on some environment variables which are not present when you run from cron? That's a common cause of problems.

sorry like what this is the script

Do you get any email notifications of errors for the user whose crontab the script is called from? If so, what?

You should check where the programs which are used in the script are located (do a "which" for each one). If any of them are outside the PATH specified in the /etc/crontab, then you will need to adjust your script to add the proper directories to the PATH.

As far as I can tell, this is all the external programs which the script calls:

• mkdir
• hostname
• tar
• mysqldump
• mount
• umount
• rsync

no i dont get any errors or emails from cron or that the script has finished or there was an error while running the script
also i have a similar script running on my other server and that works fine and they both have the same OS installed
also im running the script as root and all the paths are in the /etc/crontab/
MAILTO=support@example.net
5 1 * * Mon-Fri /root/working
what is really funny is the script runs when i do it manually
is it possible that the rysnc is taking so long over 8 hours to rsync 9G of data

Is it even running? Try changing the first line of the script to "#/bin/sh -v -x", and then append this to the crontab line which calls the script:
After the cronjob has run, post the cron.log file here.

Hi
This is the output of the cron.log

/bin/sh does not accept those arguments. Either the interpreter needs to change to /bin/bash or the OP should use:

set -v -x

inside the script. This is what is causing the error output above.

Hmm strange. There should be no space between the "-" and the "v" or "x". Perhaps you made a typo when editing the script? The first line of the script should look like this:
If that is how you have it, then it must be some weird shell which doesn't support the -v and -x options (I thought these were part of the POSIX standard... Maybe not).

So then the question becomes "what shell is it?" Some shells like (bash) support the --version option, which you can use like this (just do this in a terminal):
Hopefully you will get some output like this which itentifies the shell:
Some shells don't support the --version option. For these, maybe the /bin/sh is a symlink to a different binary. For example, on my Ubuntu system:
shows that /bin/sh is actually "dash":

There are so many variants of shell (/bin/sh) that it is very difficult to keep up current distros.

One one system:

/bin/sh --version
GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.

on a NetBSD system:

$ /bin/sh --version
sh: Illegal option --

So, less here, is to assume least common denominator sometimes.

Aha, that'll be it then.

So to the original poster:
Add this line as the second line of the script:

here is the output

That's a lot of output. It did something. Perhaps you can look through it line by line to see if there are any problems.

As an aside, this is a bit dangerous:

rm -rf /backup*

if you accidentally place a space between the p and the *, you will lose your entire system. While this is very unlikely, it is just too catastrophic if it does happen. In general:

1) don't place working stuff in /
2) be very careful with wildcards, esp with rm -rf.

When you say it stopped working, what do you mean? What do you expect to see which you do not?

Also, have a look at the /tmp/serverbk.log and see if you can see any error or failure messages in there.

the out put happened when i ran the script in the CLI
nothing happens when the crontab runs it
the serverbk.log file will be empty nothing in it its really confusing me as well