[Klug-general] Cron job

[Nathan Friend]

Thanks everyone, lot's of good script info.

I'll add some error checking and post my findings when I'm back at work
Tuesday.

Colin - Yes I can do a talk on Moodle if it's of interest...

Nathan.

On Thu, Apr 9, 2009 at 11:18 PM, Alan @ COMM-TECH <
alan at communitytechnology.org.uk> wrote:

>  Jeremy Hooks wrote:
>
> 2009/4/9 Nathan Friend <nathan.friend at gmail.com> <nathan.friend at gmail.com>:
>
>
>  Afternoon All,
> I've writen a simple script to dump a database and would like it to run as a
> cron job.  How should I set the script permisisons?
>
>
>  Presuming the cron job is being run by root you will probably want to
> make sure the script is owned by root:
> chown root.root /usr/local/script/dbbackup.sh
>
> Then you can set the permissions with so that only root has
> permissions to read/write/execute it:
> chmod 700 /usr/local/script/dbbackup.sh
> or
> chmod u=rwx /usr/local/script/dbbackup.sh
>
>
>
>  dbbackup.sh contains:
>
> NOW=$(date +"%d-%b-%y"_"%l:%M")
> FILENAME="moodle_db_backup_$NOW.sql"
> mysqldump -uuser -ppassword databasename > /dbbck/$FILENAME
>
>
>  Don't forget, ofcourse if you want the script to actually run you need
> a shebang too, e.g.:
> #!/usr/bin/bash
>
> The date format you are using will likely cause you problems as it
> will give you something like "09-Apr-09_ 8:30", a filename with a
> space in it.  With either a %I (12 hour, with leading zero) or %H (24
> hour, with leading zero) rather than %l (12 hour, leading space).
> Something else that is important to remember when writing cron scripts
> is that you can't always be certain that the path variable isn't
> necessarily the same as you would have when running running the script
> from an interactive shell.  So I would recommend changing 'mysqldump'
> to '/fullpath/mysqldump'.
>
>
>
>
>  The cron entry is
>
> 30 20 * * * /usr/local/script/dbbackup.sh
>
> I can run the script from for command line OK with the expected output.
> However wathcing /var/log/messages I see the cron job run but no output
> file...
>
>
>  One final thing, if your script running but you aren't getting the
> results you expect, it may be worth checking the output of the
> command.  Normally the output from cron scripts is emailed to the user
> using the local mail system.  You can check this by using (say) mutt
> or 'vi /var/spool/mail/root'.
>
> I think that is everything, but I don't use cron often, so I could
> have forgotten something.
>
> Regards.
>
> Jeremy
>
>
>
>  Cron is so reliable you tend to just set it and forget it, until you find
> the backup hasn't been working for 6 months because the destination was
> unreachable, or the mysql password changed or someting..
>
> I find it useful therefore to interrogate the exit code of  mysqldump so
> you could also have the script mail you if someting went wrong, so right
> after the mysqldump command use:
>
> EXITSTATUS=$?
> if [ "$EXITSTATUS" != "0" ] then
>    == send email notifying a problem with the backup==
> fi
>
> [googling..]  here's a nice little revelation on bash exit code [arrays!]:
>
> http://www.briandowney.net/blog/2008/05/05/bash-pipeline-exit-codes/
>
> Alan
>
> _______________________________________________
> Kent mailing list
> Kent at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/kent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/kent/attachments/20090410/8d191802/attachment.htm