Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an hourly cron script which take some output (a mysql dump), pipes it through gzip, and aims to overwrite a file of the same name. When I run it manually as root the file is overwritten. When it is ran by the cron daemon the filename has ".1" appended to it. This keeps happening so that after a while I have lots of files like so:


and so on.

ps aux|grep crond shows that the daemon is being run as root.

I've tried:

  • renaming the original file, pushing the output, then removing the old file on completion, and
  • deleting the original file before piping the output

but neither works as expected and I just get . files.

Script looks like this (nothing special) and is located on a CentOS box in /etc/cron.hourly:

DATE=`date +%H`
mysqldump $OPTS | gzip -9 > $DIR/$FILE

Can anyone advise as to why this simple operation isn't running as expected?

share|improve this question
If you want us to help you, you need to post the complete script. – joschi Oct 30 '09 at 9:58
It might also be helpful to show your crontab. – Dennis Williamson Oct 30 '09 at 11:58
Is this your server? This behaviour is very weird; it almost looks like someone has compiled a custom bash for it. – Zac Thompson Oct 30 '09 at 15:57
@ Zac - yes, this is my own server though I didn't build it I've been using it for the past 3 years without any issues. – Phillip Oldham Oct 30 '09 at 23:41
up vote 3 down vote accepted

Most likely, your script is written to use Bash features, but it's being run by the Bourne shell. Do you have #!/bin/bash as the first line of your script? Please post it so we can better help you.


In scripts that are meant to run as cron jobs, I always specify the full path to programs (such as mysqldump and gzip) since the $PATH variable and things like aliases are going to be different from those in your interactive shell. That way, the results are predictable.

share|improve this answer
Yes; added script to question. – Phillip Oldham Oct 30 '09 at 10:36
Looks like it was the absolute paths to the programs. Setting them fixed the problem instantly. Thanks! – Phillip Oldham Oct 30 '09 at 23:43

Try adding this line to the top of your script after the bash line

set +C

This will turn off the noclobber option in bash so should overwrite the file.

If it's not that, then it's probably something like an alias to gzip being set either by cron or your overall environment.

share|improve this answer
An alias could not do this. The script has the redirect '>' command right in the command; it will be parsed by the shell before it gets to the gzip command. – Zac Thompson Oct 30 '09 at 15:54
I assume you're talking about this line? mysqldump $OPTS | gzip -9 > $DIR/$FILE If it's an alias, the gzip command could be anything at all, and might not even be producing anything on STDOUT to be redirected, making the > redundant? It would be odd, but then this issue is pretty odd – Ewan Leith Nov 2 '09 at 9:43

Try to set #!/bin/bash -x and write /path/to/bash_script 1 > /path/to/log_file (where in /path/... set your own path to files).

share|improve this answer

That seems really strange to me, bash has a noclobber option that makes it so redirection will not overwrite a file. Maybe this a recent version a new option that is similar, but creates a .1 file instead?

Is it possible something like logrotate is called in the cronjob, or something runs right before it that moves the file (logrotate)? You should check /etc/crontab and crontab -e run as root.

Is this on some sort of cloud or shared hosting site? Maybe the provider has created something that does this to help reduce their ticket load :-)

share|improve this answer
My dump script is the only script that runs hourly, so I don't think it could be logrotate. – Phillip Oldham Oct 30 '09 at 11:59
gzip is an alias that moves the file first? Or there is a gzip in the path that moves a file first, but I don't really even so how that would work ... – Kyle Brandt Oct 30 '09 at 12:09

It's not gzip -c? That option is for writing to stdout rather than to a file. Is there a GZIP or GZIP_OPT environment variable set (with gzip options in it)?

share|improve this answer
gzip in a pipe doesn't need -c – Dennis Williamson Oct 30 '09 at 17:06
looks to be working fine without the -c option. – Phillip Oldham Oct 30 '09 at 23:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.