2

I have a command in my crontab that doesn't execute correctly, this should backup the database everyday at the specified time. I tried running the command in my terminal and is working properly.

To edit my crontab I use crontab -e the current cron tab contains the following:

# Save online agent status every 2 minutes
*/2 * * * * /usr/bin/python /home/dummy/scm/qt-savu/userstatus.py >> /home/dummy/qt-savu/userstatus.log

# Save Hourly call counts every XX:59
59 * * * * /usr/bin/python /home/dummy/scm/qt-savu/hourlylog.py >> /home/dummy/qt-savu/hourlycc.log

# Backup albatross everyday
58 5 * * * /usr/bin/mysqldump -udummy -ppassword albatross | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.albatross.tar.gz

# Backup bert everyday
58 5 * * * /usr/bin/mysqldump -udummy -ppassword bert | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.bert.tar.gz

Other commands in the crontab are working properly, The commands that are not working are:

# Backup albatross everyday
58 5 * * * /usr/bin/mysqldump -udummy -ppassword albatross | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.albatross.tar.gz

# Backup bert everyday
58 5 * * * /usr/bin/mysqldump -udummy -ppassword bert | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.bert.tar.gz

The log output looks like this

Sep  4 05:56:01 luna CRON[18815]: (dummy) CMD (/usr/bin/mysqldump -udummy -ppassword bert | /bin/gzip > /home/dummy/Documents/backups/`/bin/date '+)
Sep  4 05:56:01 luna CRON[18812]: (CRON) info (No MTA installed, discarding output)
Sep  4 05:56:01 luna CRON[18817]: (dummy) CMD (/usr/bin/mysqldump -udummy -ppassword albatross | /bin/gzip > /home/dummy/Documents/backups/`/bin/date '+)
Sep  4 05:56:01 luna CRON[18813]: (CRON) info (No MTA installed, discarding output)

As I observed the output of the log stops at /bin/date.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
  • 1
    I would recommend you put you commands into a shell scripts and then call these to keep the crontab simple to read – albal Sep 03 '15 at 22:25
  • thanks for the tip, doesn't it increase the complexity? – Irvin Denzel Torcuato Sep 03 '15 at 22:29
  • Nope, it does not increase complexity. It actually simplifies management if you ask me. That way the crontab simple manages when tasks are run and then the tasks in the shell scripts can be as simple or complex as need be. The problem with adding inline commands in the crontab is sometimes syntax issues caused by cramming one-liners into that format actually cause more headaches down the line. – Giacomo1968 Sep 04 '15 at 02:15

1 Answers1

4

% is treated specially by cron. It is used to denote the end of the command portion and the beginning of standard input. As such, you must escape it, like so: \%.

From the crontab man page:

The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the crontab file.

alienth
  • 321
  • 2
  • 5
  • God sent, been troubled by this for more than an hour... is there a list of special chars in the man pages? That explains the weird syntax highlighting - (edit) – Irvin Denzel Torcuato Sep 03 '15 at 22:21
  • Per the manpage (`man 5 crontab`), the sixth field only has that one special character. – alienth Sep 03 '15 at 22:29
  • @IrvinDenzelTorcuato Also—as discussed in the comments to your initial question—this is why it is highly recommended that you let the crontab entries just call a script and then dump all the core logic in a standalone script. In this case, I am quite positive the problem would be solved with a standalone script. Not saying this answer is wrong—it’s correct—but it also shows the pitfalls of mucking up shell script one-liners in crontab commands. – Giacomo1968 Sep 04 '15 at 02:21