Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Shell script and CRON problems [closed]

I've written a backup script for our local dev server (running Ubuntu server edition 9.10), just a simple script to tar & gzip the local root and stick it in a backup folder. It works fine when I run :

$ bash backups.sh

but it wont work when I run it through crontab.

59 23 *  *  *  bash /home/vnc/backups/backup.sh >> /home/vnc/backups/backup.log 2> $1

I get the error message

/bin/sh: cannot create : nonexistent

The script makes the tar.gz in the folder it is running from (/home/user1), but then tries to copy it to a mounted share (/home/backups, which is really 192.168.0.6/backups) from a network drive, via using fstab. The mounted share has permissions 777 but the owner and group are different to those running the script. I'm using bash to run the script instead of sh to get around another issue I've had in the past with "bad substitution" errors

The first 2 lines of the file are

! /bin/bash

cd /home/vnc/backups

I'm probably not supplying enough information to fully answer this post yet but I can post more information as necessary, but I don't really know where to look next.

like image 203
Pete Avatar asked Feb 26 '23 01:02

Pete


2 Answers

The clue is in the error message:

/bin/sh: cannot create : nonexistent

Notice that it says "sh". The Bourne shell doesn't support some features that are specific to Bash. If you're using Bash features, then you need to tell Bash to run the script.

Make the first line of your file:

#!/bin/bash

or in your crontab entry do this:

* * * * * /bin/bash scriptname

Without seeing your crontab entry and your script it's hard to be any more specific.

like image 128
Dennis Williamson Avatar answered Feb 27 '23 15:02

Dennis Williamson


Perhaps the first thing you should do in your backups.sh is insert a cd /home/user1. crond may execute your script from a different directory than you think it does, and forcing it to use the same directory regardless of how it is executed could be a good first start.

Another potentially useful debugging step is to add id > /tmp/id.$$ or something like that, so you can see exactly which user account and groups are being used to run your script.

like image 25
sarnold Avatar answered Feb 27 '23 15:02

sarnold