6

I'm new on linux user

I try to run crontab to backup my database with vagrant user

* * * * * /usr/bin/mysqldump -h localhost -u root -p root mydb | gzip > /var/backup/all/database_`date +%Y-%m-%d`.sql.gz >/dev/null 2>&1

when the crontab runs there is no backup file in the folder (my backup/all has the permission scheme 755).

This is error from /var/log/syslog

Aug 16 11:55:01 precise64 CRON[2213]: (vagrant) CMD (/usr/bin/mysqldump -h localhost -u root -p root mydb | gzip > /var/backup/all/database_`date +%Y-%m-%d`.sql.gz >/dev/null 2>&1)
Aug 16 11:55:01 precise64 CRON[2212]: (CRON) info (No MTA installed, discarding output)

So I think

  1. it's about crontab can't create backup file because of Permission denied.
  2. it's about I'm didn't install MTA but I use >/dev/null 2>&1 to disable crontab to sent it to email why it error ?
  • What is the owner of /var/backup/all? As you use the full path with mysqldump, could you to use it too with gzip? – Volker Siegel Aug 16 '14 at 17:13
  • Thanks you for help. The owner of /var/backup/all is root (I don't know how to create folder with out sudo) I which mysqldump is /usr/bin/mysqldump and which gzip is /bin/gzip. – Kanin Peanviriyakulkit Aug 16 '14 at 17:33
11

Of course, the error is that you don't have a mailer (sendmail,postfix, etc) implemented and active.

That being said your other problem is that the >/dev/null 2>&1 ONLY only applies/associates to the LAST command in this case gzip. Thus there must be some type of output going to STDERR for your mysqldump.

The correct way to do what I think you want is:

 * * * * *  (command | command ) >/dev/null 2>&1
  • Thanks you for help. But I have a problem that I think about permission. It didn't create a backup file I use crontab -e with vagrant user but my folder is create by root (via sudo) so I thinking about chown user for folder right ? – Kanin Peanviriyakulkit Aug 16 '14 at 20:09
  • @KaninPeanviriyakulkit yes, that's right, see the first part of my answer. – Volker Siegel Aug 16 '14 at 21:56
  • @mdpc The output of the last command, gzip, goes to the dump file. It makes no sense to somehow write filedescriptor 1 to /dev/null too. The >/dev/null 2>&1 applies to the error stream of gzip only, that's right. – Volker Siegel Aug 16 '14 at 22:03
  • It sets the descriptor to a designated default until changed by an underlying command. This format would be good so that in the future if other commands and such are added to the line, you will not have to worry about this particular problem again. – mdpc Aug 16 '14 at 22:20
5

You can put:

MAILTO=""

at the beginning of your crontab file and that will prevent it from trying to send email.

1

If the user running the crontab command is vagrant, and the directory where the output is written to is owned by root, and has permissions 755, it can not be written to.
sudo chown vagrant /var/backup/all
may fix that.

To check whether that's the problem, try writing to a file in /tmp instead.

But there is another problem: A command like
mysqldump mydb | gzip > database.sql.gz >/dev/null 2>&1
writes the database dump to database.sql.gz and to /dev/null.
The 2>&1 copies the error messages to the standart output, that means it also writes the error messages to database.sql.gz. It writes error message text just some where in between the compressed data, so the compressed file will be broken. Note it may work well when testing - as the problem only occurs when something is written to the standard error stream. The output to stderr may be just a warning, while everything else works.

I assume you intend to write the compressed database dump to the sql.gz file, and the errors to /dev/null. For this, just keep the output streams separate, by not copying the error stream to the output stream. And direct them to the files like this:

mysqldump mydb | gzip > /var/backup/all/database_`date +%Y-%m-%d`.sql.gz 2>/dev/null

The error message "(No MTA installed, discarding output)" is cron telling you that it can not send you the error output. That will be no problem in the end as you redirect errors to /dev/null anyway, there will be nothing to send. But I suspect that currently there are error messages to send, that should confirm my findings above.

  • You still need to handle the STDERR on the mysqldump seperately as the pipe will only handle STDOUT. – mdpc Aug 16 '14 at 22:18
  • I see, that's right. Then, it would be (command | gzip > foo.gz ) 2>/dev/null? – Volker Siegel Aug 16 '14 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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