Bash-Skript läuft auf einem Server nicht 100% als Cronjob

A

Amyris

New Member
Hallo,

ich habe ein Bash- und ein Perl-Skript. Beide verwende ich für eine Datensicherung des Dateisystems und der MySQL-Datenbanken auf ein angeschlossenes NFS-Laufwerk.

Mein Problem ist nun:
Führe ich diese Skripte manuell z.B. in einem Screen aus, läuft alles wunderbar fehlerfrei durch. Lass ich die gleichen Skripte als Cronjob laufen, dann läuft die Datensicherung nicht komplett durch (es werden viel weniger GB gesichert als bei manuellem Anstoßen) und die MySQL Sicherung gar nicht.
Ich habe die Skripte sowohl schon als root-User per "crontab -e" aufgerufen, als auch direkt über die /etc/crontab Datei (auch hier mit Angabe, dass das Skript als root ausgeführt werden soll). Beides macht keinen Unterschied.

Zudem kommt hinzu, dass beide Skript in absolut identischer Form auf einem anderen Server problemlos als Cronjob laufen.


Hier die Skripte. Aufgerufen wird sowohl manuell als auch per cronjob das Skript "backup-bsm", welches im Verlauf das 2. Skript "backupdb.pl" aufruft. Speicherort beider Skripts ist "/usr/local/bin".

=> backup-bsm
Code: 
#!/bin/bash

## Systemsicherung
## ===============
# Fullbackup mit Ausnahme der Excludeverzeichnisse (siehe exclude-Datei)
tar --exclude-from=/usr/local/bin/exclude -cvzf /backup/fullbackup.tar.gz /;

# Fullback Datum hinzufügen und verschieben
mv /backup/fullbackup.tar.gz /nfs-backup/backup/servername/fullbackup`date +"%F"`.tar.gz;


## Datenbankensicherung
## ====================
# Fullbackup aller Datenbanken in einzelne Dateien mittels externen Skript
/usr/local/bin/backupdb.pl;

# Datenbanken tarball
tar -cvzf /backup/mysql_dumps.tar.gz /backup/mysql_dumps;

# Datenbanken verschieben und mit Datum versehen
mv /backup/mysql_dumps.tar.gz /nfs-backup/backup/servername/mysql_dumps`date +"%F"`.tar.gz;

# Databankbackupverzeichnis fuer naechste Sicherung leeren
rm -rf /backup/mysql_dumps/*;


Wie ihr seht wird in diesem bash-Skript ein weiteres Perl-Skript (backupdb.pl) zur Datenbanksicherung aufgerufen:

=>backupdb.pl
Code: 
#!/usr/bin/perl

my $debug = 1;
my $backup_dir = "/backup/mysql_dumps/";


my $tmp_db = `/usr/bin/mysql -B --skip-column-names -e "show databases"`;
my @db_array = split(/\n/, $tmp_db);

foreach $db (@db_array)
{
        print "Backup Database $db\n" if $debug == 1;
        `/usr/bin/mysqldump --add-drop-table -B $db > $backup_dir/$db.sql`;
}


Wie gesagt, diese beiden Skripte laufen auf einem anderen Server (beides Ubuntu, Gutsy Gibbon) als Cronjob absolut fehlerfrei.
Aber eben auf dem einen Server läuft das ganze nur dann fehlerfrei durch, wenn ich es manuell starte. Als Cronjob läuft dann der Datensicherungsteil nur unvollständig (manuell werden ca. 30 GB im ZIP-File gesichert, als Cronjob sind es nur 6 GB im ZIP-File) und die MySQL Sicherung gar nicht (es wird nur ein leeres ZIP-File erstellt.

Kann mir hier jemand bei diesem Problem helfen?
 
Last edited by a moderator:
Ich bekomme diesbezüglich von crond keine Mails bzw. Fehler. Wenn ich als root eingeloggt bin und "mail" eingebe, bekomme ich jedenfalls nur "no mail for root".

In der Crontab ist auch keine Umleitung diesbezüglich eingetragen. Die derzeit für das Skript benutzte crontab (/etc/crontab) sieht derzeit folgendermaßen aus:

Code: 
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file.
# This file also has a username field, that none of the other crontabs do.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
47 6    * * 7   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly
52 6    1 * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly
00 1    * * *   root    /usr/local/bin/backup-bsm
#


Auch im Syslog sehe ich nur, dass das Skript definitiv aufgerufen wird (logisch, es wird ja auch etwas gesichert, nur eben viel zu wenig bzw. im Fall der Datenbanken gar nichts).
 
Dann füge mal noch eine Zeile ein:
Code: 
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
[B]MAILTO=root[/B]
 
Hallo LinuxAdmin,

habe diese Zeile hinzugefügt in die /etc/crontab-Datei (in welcher auch das Skript ausgeführt wird). Bekomme aber auch nach mehrmaligen Durchlauf des Skripts (welches nach wie vor als Cronjob nicht vollständig das tut was es soll - s.o.) keine Mails an root. D.h. der Befehl "mail" liefert nur ein "no mails for root" zurück.
 
Als nächstes solltest Du prüfen, wohin die Mails an root gehen. Dazu würde ich einen neuen Cronjob einrichten mit folgenden kleinem Script:
Code: 
#!/bin/bash

echo "Hallo, diese Mail wurde vom Cronjob ausgelöst"

/usr/bin/date > /tmp/cronjobtimestamp.$$
#
in /tmp siehst Du dann die Beweise, dass das Script tatsächlich ausgeführt wurde. Der auf stdout ausgegeben Text "Hallo..." sollte dafür sorgen, dass die Ausgabe per Mail verschickt wird. Nachdem der Job gelaufen ist, schaust Du Dir /var/log/mail an und suchst nach dem entsprechenden Zeitpunkt und der Mail an root. Das sollte Dir genaue Informationen über den Verbleib der Mail liefern.
 
You must log in or register to reply here.
Back
Top