Crontab Bash Problem

W

Wolfi83

Hello there,

I have great problems with crontab and bash-shells
I wrote some shells for mysql-backup and some other features.
The crontab does not execute the bash-shells, whats the problem?
I am not very special at crontab, so i need help, it is very important for me.
Is it important, to set a new PATH like:

Code: 
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin[color="Red"](:/usr/bin/env:/usr/local/bin/bash)[/color]
And the SHELL like:
Code: 
SHELL=/bin/sh[color="Red"](:/bin/bash)[/color]
 
Hello,

Problem is fixed now, had an error in my syntax
It must like look this:
Code: 
*	*	*	*	*   root	/usr/local/bin/bash   /root/backup.sh
 
Hey,

Now i got a other problem with crontab and bash -.-
If i run the backup-shell via terminal (bash backup.sh) it run AND works.
If the crontab run the backup-shell every minute (/usr/local/bin/bash /root/backup.sh) it run but do not work, on my log theres a error '127' which comes from mysqldump?
 
If i set the real bin-paths it works, but i want to have it via which-xxx u know?
so i have to add a line in pfad/shell at crontab file?
 
Wolfi83,

you may want to make use of the search path. From your postings, I'm able to suggest to make yourself more familiar with how the shell really works. The environment of cron is different to your interactive shell.

Running a complex script every minute from cron may not be a good idea. Depending on how clever you've written your script and how long it takes to complete, it may end in overlapped running scripts disturbing each other.
 
vwe@ said:
Wolfi83,

you may want to make use of the search path. From your postings, I'm able to suggest to make yourself more familiar with how the shell really works. The environment of cron is different to your interactive shell.

Running a complex script every minute from cron may not be a good idea. Depending on how clever you've written your script and how long it takes to complete, it may end in overlapped running scripts disturbing each other.
Click to expand...

That was only a test for every minute
 
Also, please consider running jobs from the root user's crontab (crontab -e), not from the system crontab in /etc/crontab. The latter can be altered or overwritten during an OS upgrade.
 
Any changes you make to root's crontab via # crontab -e are permanently saved in the file /var/cron/tabs/root. (That's just FYI. Do not edit that file directly. Use the command instead.)

As for the more general topic, unless your scripts really require bash (i.e. they use arrays or certain environment variables), you might consider writing them for Bourne shell (sh(1)). The primary argument for this approach is portability -- in my case that means a large number of scripts can be shared between FreeBSD and Linux servers, the former of which may or may not have bash installed.
 
So the crontab is saved if i reboot the system and after the systemreboot i dont have to add the crontab again?
 
DutchDaemon said:
Also, please consider running jobs from the root user's crontab (crontab -e), not from the system crontab in /etc/crontab. The latter can be altered or overwritten during an OS upgrade.
Click to expand...

On other hand you can forget to backup root crontab :D and lose it next time you reinstall :D
 
Wolfi83 said:
So the crontab is saved if i reboot the system and after the systemreboot i dont have to add the crontab again?
Click to expand...

Si, senor. Assuming you follow the recommendations on this thread.
 
anomie said:
So back it up. :) Or use one of the handy dump(8) tutorials you've written and advocated in favor of for disaster recovery.
Click to expand...

So, why is it better to write to root contab, instead of system contab?
I write to system contab, because when I do dangerous things, I backup whole /etc/
However I usually forget about stuff in /var/

That's 2 Cents.
What I'm saying is that it really doesn't matter where you write it. If you're not careful, you will have to write it again :D
 
/etc/crontab has a higher likelihood of being overwritten during an upgrade. (You could probably manage that possibility with mergemaster(8), though.) On top of that, my gut feeling is most sysadmins would be surprised to see /etc/crontab tweaks on a system they inherit. It's not a usual place for customizations, IMO.

If you don't like the idea of using root's crontab, you can always add a periodic(8) job instead.
 
anomie said:
/etc/crontab has a higher likelihood of being overwritten during an upgrade. (You could probably manage that possibility with mergemaster(8), though.) On top of that, my gut feeling is most sysadmins would be surprised to see /etc/crontab tweaks on a system they inherit. It's not a usual place for customizations, IMO.
Click to expand...

At least that makes some sense.
I've ready many times "Don't use system contab, use root crontab", however no further explanation.
Thanks
 
Did you seriously miss this in the post I dedicated to not using the system's crontab ten posts up?

The latter can be altered or overwritten during an OS upgrade.
Click to expand...
 
DutchDaemon said:
Did you seriously miss this in the post I dedicated to not using the system's crontab ten posts up?
Click to expand...

Nope... simply, that doesn't concern me, as I'm super careful with mergemaster
 
You must log in or register to reply here.
Back
Top