# Cron + rsnapshot interaction fails to parse arguments



## mix_room (Aug 11, 2009)

I have a backup script in order to backup a MySQL-database to my backup server. 

I run rsnapshot from cron at defined intervals. This works correctly. 

Rsnapshot calls a script (backup_script parameter) which calls mysql_dump. 

The script works perfectly from the command line. Rsnapshot does not return any errors when i run it from CLI either (rsnapshot hourly)

When rsnapshot is run from cron I get an error message delivered to the email which states 

```
--host host.domain.tld    not found
```

The line in the backup script is as follows 


```
$mysqldump --host $host.$domain ...additional parameters > $GZIP
```

I used to have 
	
	



```
--host "$host.$domain"
```
, but that returned errors aswell. 

My cron enviroment sets the shell to /bin/sh. 

As the task runs quite frequently my inbox is filling up. I would greatly appreciate any help. Should it be necessary I can post my scripts once I have access to the machine in question.


----------



## DutchDaemon (Aug 11, 2009)

It is not consistent with the error message, but try one of these:

1. setting cron's PATH to include the directory to the mysqldump binary
2. using full pathnames in any script executed from cron


----------



## DutchDaemon (Aug 11, 2009)

Oh, wait a minute ...


```
o  --host=host_name, -h host_name
```

It's one or the other


----------



## mix_room (Aug 11, 2009)

DutchDaemon said:
			
		

> 1. setting cron's PATH to include the directory to the mysqldump binary





> 2. using full pathnames in any script executed from cron



I already did that. I use full pathnames both in cron and in the backup script



> Oh, wait a minute ...
> 
> 
> ```
> ...



I will check that, but I think that I have already used --host=host_name. I was retyping the script from memory when I posted my original question.


----------



## DutchDaemon (Aug 11, 2009)

Ok, if the problem persists, try running the script from cron with '/bin/sh -xv' in front of it to capture the full output. See how all of the variables expand as seen from cron.


----------



## mix_room (Aug 13, 2009)

As suggested I ran the backup script from rsnapshort using '/bin/sh -xv'. Output is attached below. 

```
#!/bin/sh
# Use mysqldump to dump a database to a compressed file.
# In order to restore the database run the following command
# gunzip < BACKUP.GZ | mysql --user --host -p DATABASE

MUSER="SECRETUSER"
+ MUSER=SECRETUSER
MPASS="SECRETPASSWORD"
+ MPASS=SECRETPASSWORD
MHOST="sqlhost"
+ MHOST=sqlhost
MDOMAIN="domain.tld"
+ MDOMAIN=domain.tld

DATABASE="db1 db2"
+ DATABASE=db1 db2
DATE=`date -j "+%Y%m%d"`
+ date -j +%Y%m%d
+ DATE=20090813
OUTPUT="${MHOST}_${DATE}.mysql.gz"
+ OUTPUT=sqlhost_20090813.mysql.gz

MYSQL=`which mysql`
+ which mysql
+ MYSQL=
MYSQL_DUMP=`which mysqldump`
+ which mysqldump
+ MYSQL_DUMP=
GZIP=`which gzip`
+ which gzip
+ GZIP=/usr/bin/gzip

$MYSQL_DUMP --host=$MHOST.$MDOMAIN --user=$MUSER --password=$MPASS --databases $DATABASE | $GZIP -9 > $OUTPUT
+ + --host=sqlhost.domain.tld /usr/bin/gzip --user=SECRETUSER -9 --password=SECRETPASSWORD
 --databases db1 db2
--host=sqlhost.domain.tld: not found
```


----------



## DutchDaemon (Aug 13, 2009)

Was this run from cron?

Two things jump to the eye:

```
MYSQL=`which mysql`
+ which mysql
+ [B]MYSQL=[/B]
MYSQL_DUMP=`which mysqldump`
+ which mysqldump
+ [B]MYSQL_DUMP=[/B]
```

Both are empty, which means the actual command line becomes:

```
[empty] --host=$MHOST.$MDOMAIN
```

And [cmd=]--host[/cmd] is not a valid command.

Find out why [cmd=]which mysql[/cmd] and [cmd=]which mysqldump[/cmd] fail (I think you may have to add /usr/local/bin to cron's PATH setting(*)), or just put the full path in the variables yourself.

(*) put PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin as the first line in the crontab


----------



## mix_room (Aug 13, 2009)

DutchDaemon said:
			
		

> Was this run from cron?


Yes. I ran rsnapshot from cron. rsnapshot then ran the backupscript. 



> Both are empty, which means the actual command line becomes:
> 
> ```
> [empty] --host=$MHOST.$MDOMAIN
> ...


Which should be quite obvious. Thank you for pointing that out. 




> Find out why [cmd=]which mysql[/cmd] and [cmd=]which mysqldump[/cmd] fail (I think you may have to add /usr/local/bin to cron's PATH setting(*)), or just put the full path in the variables yourself.



Will do. 

I'll let you know how this works out once it has been implemented.


----------



## mix_room (Aug 14, 2009)

I made some changes to my script: 

1) Output $PATH

```
echo $PATH
+ echo /usr/bin:/bin
/usr/bin:/bin
```
Seems as though $PATH is not complete, that explains why mysqldump was not found. 
I also added the direct path: 

```
MYSQL="/usr/local/bin/mysql"
+ MYSQL=/usr/local/bin/mysql
MYSQL_DUMP="/usr/local/bin/mysqldump"
+ MYSQL_DUMP=/usr/local/bin/mysqldump
GZIP=`which gzip`
+ which gzip
+ GZIP=/usr/bin/gzip
```

It seem's as though it has worked. 

```
$MYSQL_DUMP --host=$MHOST.$MDOMAIN --user=$MUSER --password=$MPASS --databases $DATABASE | $GZIP -9 > $OUTPUT
+ + /usr/local/bin/mysqldump/usr/bin/gzip --host=sqlhost.domain.tld -9 --user=SECRETUSER
 --password=SECRETWORD --databases db1 db2
```

One question that remains: the output of the last line ($mysqldump ARGS | $gzip ARGS) seems odd. Is this a problem, or just due to the output formatting of /bin/sh?

Greatly appreciate your help.


----------



## DutchDaemon (Aug 14, 2009)

Yes, that looks like an artefact of the shell trying to put verbose output on a single line. Looks like a small race condition. It sometimes happens when shutting down the OS as well, when the OS starts printing a lot of information in a very short time, leading to garbled output. It's not a problem.


----------



## DutchDaemon (Aug 14, 2009)

As for the script itself: I think adding that PATH to the top of the crontab is the cleaner solution. By default, cron doesn't know about the executables in /usr/local, whereas the 'user shell' does. So just nudge cron to use the extended path.


----------



## mix_room (Aug 14, 2009)

DutchDaemon said:
			
		

> As for the script itself: I think adding that PATH to the top of the crontab is the cleaner solution. By default, cron doesn't know about the executables in /usr/local, whereas the 'user shell' does. So just nudge cron to use the extended path.



I agree that adding /usr/local/ in cron's PATH is the cleaner solution. However it was not the quick-n-dirty solution.


----------



## mix_room (Aug 17, 2009)

It works now. 

I added the entire $PATH from my normal shell to cron. That seems to have solved the problem. Now my mailbox doesn't fill up every day. 

Thanks again for the help.


----------



## DutchDaemon (Aug 17, 2009)

Cheers.


----------

