Daily Cron Not Running Properly

Deemar · 03-23-2017, 11:36 AM

I placed a file named database-export into my /etc/cron.daily folder with the following lines in it:

Code:

#!/bin/sh

mysqldump -u cronexport -h development.companydomain.com company_development > /home/daniel/Documents/backups/development-cron.sql

When I run the daily cron jobs manually, it executes perfectly and creates the database dump in the folder specified. However if I leave it overnight and let it execute on its own, it creates the file with a lock symbol on it and it's empty. Is it running the cron job as a different user or with different permissions or something? I created the cron file using sudo if that matters.

Thanks.

TB0ne · 03-23-2017, 12:25 PM

Quote:

Originally Posted by Deemar

I placed a file named database-export into my /etc/cron.daily folder with the following lines in it:

Code:

#!/bin/sh
mysqldump -u cronexport -h development.companydomain.com company_development > /home/daniel/Documents/backups/development-cron.sql

When I run the daily cron jobs manually, it executes perfectly and creates the database dump in the folder specified. However if I leave it overnight and let it execute on its own, it creates the file with a lock symbol on it and it's empty. Is it running the cron job as a different user or with different permissions or something? I created the cron file using sudo if that matters.

The first/best rule for ANY cron job is "NEVER assume your path is right"

Think about it: when you log in, you get your .bashrc/.bash_profile and the system profile executed, right? That sets your PATH, allowing you to type in such things as "mysqldump". When cron is doing it..none of those things happen; NOTHING gets inherited. So specify "/usr/bin/mysqldump" (or wherever you have it) andit may work fine. Also, you're specifying a user (cronexport) for mysqldump...does that user need a password?

szboardstretcher · 03-23-2017, 12:43 PM

Quote:

Originally Posted by TB0ne

The first/best rule for ANY cron job is "NEVER assume your path is right"

Either before or after that is "Never assume your script is running as the correct user."

TB0ne · 03-23-2017, 02:20 PM

Quote:

Originally Posted by szboardstretcher

Either before or after that is "Never assume your script is running as the correct user."

Indeed!

Also OP, in that vein..you can export variables and other such things in your bash shell script, so if you have something that winds up being a huge hairball (like Oracle?) where you have to set multiple environment variables and the like, you can still do it. Bang this into a script:

Code:

for i in `env | sed 's/=.*//'` ; do
    unset $i
done

..and run it. THEN try to run your script manually. The above code flushes/resets EVERY environment variable you have...so if your script depends on it, it will die and you'll know what to fix.

deleted23 · 03-26-2017, 04:14 PM

To a cron-job always belong two parts - the cron-job and the script you'd like to execute.
Perhaps it be a good idea to post both?

Also it seems that the same one-liner did it's job already.

Quote:

When I run the daily cron jobs manually, it executes perfectly and creates the database dump in the folder specified.

Important for the proper execution of your job is a carefully set up environment for the job.
It won't work if you try to setup an environment in the shellscript because when the shellscript tries to start executing it's 'already too late' and the script got spawned by the parent process.

Put all necessary environment variables in the cronjob.
Trying to implement a 'control-instance' in form of a popping up window for failures or similar without using the c-preprocessor is a very challenging task by itself too but that's off-topic.

Question:

Did you change something in your configuration which could have lead to the faulty behaviour?

Murphy's law: never change a running system ;-)

michaelk · 03-26-2017, 06:34 PM

Welcome to LinuxQuestions.

In addition, what triggers scripts in /etc/cron.daily depends on the distribution/version but typically jobs are run as root.

Deemar · 03-29-2017, 10:15 AM

Thanks, it appears I may need to add some paths into the file. This concept is new to me, any suggestions what I should be adding to let this run? Right now I still have the file the same as it was in the original post.

suicidaleggroll · 03-29-2017, 11:18 AM

Ignore cron.daily, and don't use sudo. Open a terminal as your regular user, the same one you want to run the command, and run "crontab -e". That will edit that user's personal crontab. The first 5 columns control the day/time the command is run, if you want to run at 00:00 local time every day then use "0 0 * * *". After that comes the command. Never assume your PATH is correct, always use the absolute path to any commands. The final entry should look similar to:

Code:

0 0 * * * /path/to/mysqldump -u cronexport -h development.companydomain.com company_development > /home/daniel/Documents/backups/development-cron.sql

You can add comments to the crontab by prefixing any line with "#". I always put the following at the top of my crontab as a reminder to myself:

Code:

#
# Cron's default PATH:
#    /usr/bin:/bin
#
#   *  *  *  *  *  command to be executed
#   -  -  -  -  -
#   |  |  |  |  |
#   |  |  |  |  +----- day of week (0 - 6) (Sunday=0)
#   |  |  |  +------- month (1 - 12)
#   |  |  +--------- day of month (1 - 31)
#   |  +----------- hour (0 - 23)
#   +------------- min (0 - 59)

Deemar · 03-29-2017, 12:42 PM

Quote:

Originally Posted by suicidaleggroll

Ignore cron.daily, and don't use sudo. Open a terminal as your regular user, the same one you want to run the command, and run "crontab -e". That will edit that user's personal crontab. The first 5 columns control the day/time the command is run, if you want to run at 00:00 local time every day then use "0 0 * * *". After that comes the command. Never assume your PATH is correct, always use the absolute path to any commands. The final entry should look similar to:

Code:

0 0 * * * /path/to/mysqldump -u cronexport -h development.companydomain.com company_development > /home/daniel/Documents/backups/development-cron.sql

You can add comments to the crontab by prefixing any line with "#". I always put the following at the top of my crontab as a reminder to myself:

Code:

#
# Cron's default PATH:
#    /usr/bin:/bin
#
#   *  *  *  *  *  command to be executed
#   -  -  -  -  -
#   |  |  |  |  |
#   |  |  |  |  +----- day of week (0 - 6) (Sunday=0)
#   |  |  |  +------- month (1 - 12)
#   |  |  +--------- day of month (1 - 31)
#   |  +----------- hour (0 - 23)
#   +------------- min (0 - 59)

Thanks for that. Should I be ignoring the daily system that Ubuntu has migrated to though? I was thinking if that's the way they're moving then I should embrace it, it must be better somehow.

suicidaleggroll · 03-29-2017, 12:59 PM

There's nothing wrong with cron.hourly, cron.daily, cron.weekly, etc., but those are really more for system maintenance types of jobs (logrotate, mlocate, etc). They're not new, they've been around for many many years, but they're not built for user-specific jobs like this, so they're not going to replace users' personal crontabs. Different tools for different jobs.

As a general rule, if it requires root/sudo access, then you shouldn't be doing regular user tasks with it. Regular user tasks should be implemented using regular user commands, if it needs elevated privileges then you're likely doing something wrong.

Deemar · 03-29-2017, 04:03 PM

Quote:

Originally Posted by suicidaleggroll

Ignore cron.daily, and don't use sudo. Open a terminal as your regular user, the same one you want to run the command, and run "crontab -e". That will edit that user's personal crontab. The first 5 columns control the day/time the command is run, if you want to run at 00:00 local time every day then use "0 0 * * *". After that comes the command. Never assume your PATH is correct, always use the absolute path to any commands. The final entry should look similar to:

Code:

0 0 * * * /path/to/mysqldump -u cronexport -h development.companydomain.com company_development > /home/daniel/Documents/backups/development-cron.sql

You can add comments to the crontab by prefixing any line with "#". I always put the following at the top of my crontab as a reminder to myself:

Code:

#
# Cron's default PATH:
#    /usr/bin:/bin
#
#   *  *  *  *  *  command to be executed
#   -  -  -  -  -
#   |  |  |  |  |
#   |  |  |  |  +----- day of week (0 - 6) (Sunday=0)
#   |  |  |  +------- month (1 - 12)
#   |  |  +--------- day of month (1 - 31)
#   |  +----------- hour (0 - 23)
#   +------------- min (0 - 59)

Cool, thanks (and to the poster above this). I implemented this, now do I need to run any other command after that? Is there some sort of push I need to do in order to make this cron job live or something? Also, how do I know where the path to mysqldump is? It's a default command line tool used with MySQL databases, it's included with them. I can run it from anywhere.

michaelk · 03-29-2017, 04:33 PM

No, cron will automatically read your crontab files when you exit the editor. To find the path to mysqldump you can try the following commands.

which mysqldump
locate mysqldump

IMHO sort of straddling the line here and a mysqldump could be considered a system maintenance task..