Probleme beim Starten eines Scripts per Cron

[mario m]

Hallo zusammen

Ich habe ein merkwürdiges Problem im Zusammenhang mit Cron.
Mein Backupscript läuft von der Konsole ohne Probleme. Im Script wird ein Tar Archiv gemacht, und auf DVD gebrannt. Anschliessend wird die MD5 Summe der Datei auf der Harddisk mit der auf der DVD verglichen.

Als Cronjob hat es bisher auch ohne Probleme funktioniert. (Pfade, ENV Variablen etc. sollten also nicht das Problem sein)

Wenn das Script nun nachts aufgerufen wird, habe ich im Syslog folgende Meldungen:

Code: Alles auswählen

Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940404, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985100
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940408, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985101
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940412, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985102
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940416, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985103
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940420, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985104
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940424, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985105
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940428, limit=3940032
Apr  1 22:45:06 localhost kernel: Buffer I/O error on device hdc, logical block 985106
Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940036, limit=3940032

Die Meldungen erscheinen erst, wenn ich die MD5 ab der DVD mache.

Wenn ich aber das Script manuell starte, läuft alles ohne Probleme durch. Die MD5 wird von beiden Dateien berechnet und verglichen…. Sie wird auch in die Logdatei geschrieben:

Code: Alles auswählen

MD5 Summe auf der Harddisk: 7c063e193c0974ea784521dfb18a67bf
MD5 Summe auf der DVD     : 7c063e193c0974ea784521dfb18a67bf

Wie kann das Sein? Ein defekt des Mediums kann ich auch ausschliessen, 1. weil ich es bereits mit ganz neuen DVDs Probiert habe und 2. weil alles funktioniert wenn ich es manuell starte.
Ich bin echt ratlos und für Hilfe sehr dankbar.

Gruss
Mario

[cosmac]

hi,

auf den ersten Blick sieht das aus wie das alte readahead Problem:
http://www.google.de/search?hl=en&q=rea ... arch&meta=

Aber warum passiert das nur im cronjob? Bist du sicher, dass du
exakt die gleichen Daten verwendet hast? Das readahead Problem
ist nämlich von der Datenmenge auf der DVD abhängig.

Als Abhilfe könntest du die DVD mit dem eject-Befehl auswerfen,
anschliessend mounten und dann die md5sum der Datei und
nicht die des Images vergleichen.

[mario m]

Hallo

Danke für deine Antwort.

Bist du sicher, dass du
exakt die gleichen Daten verwendet hast?

Ja, zu 100% sicher. Ich habe in der Crontab /etc/backup/backup.sh drinnen,
und dieses script starte ich auch aus der Bash.
(Ich habe es unter etc abgelegt, damit das Backupscript auch gesichert wird... )

Als Abhilfe könntest du die DVD mit dem eject-Befehl auswerfen,
anschliessend mounten und dann die md5sum der Datei und
nicht die des Images vergleichen.

Diese Antwort habe ich nicht ganz verstanden.
Nach dem Brennen mounte ich die DVD. Ich mache die Prüfsumme ab der Datei auf
der DVD.

Das Eject mache ich am Ende des Backups, WENN es erfolgreich war.
Würde ein eject + Mount e.v. das Problem lösen? Ich denke nicht, da es aus der Konsole ja
auch geht ohne neues mounten.

Hast du mir genauere Infos über den eadahead Bug?
Ich habe irgendwo folgende aussage gefunden:

NOTE: Some operating systems have a read ahead bug that causes I/O errors for
the last file(s) on a CD. This seems at least to be true for all Linux versions
and for Solaris 7 FCS. For Solaris 7 there is a patch (107465-02) that you should
install. This I/O error problem does not occur with DAO disks and with TAO disks
that have been written with cdrecord -pad.

http://www.linux4all.de/livecd/barebone ... DME.verify
Tritt dieses Problem wirklich nur bei der letzten Datei auf?
Falls ja, könnte ich einfach eine 2. "dummy" Datei auf die DVD Brennen.

Mario

[cosmac]

Bist du sicher, dass du
exakt die gleichen Daten verwendet hast?

Ja, zu 100% sicher. Ich habe in der Crontab /etc/backup/backup.sh drinnen,
und dieses script starte ich auch aus der Bash.

das ist schonmal gut, aber ich meinte, ob beide Male die gleichen
Daten auf der DVD waren. Weil der Fehler je nach Anzahl der belegten
Sektoren auftritt oder nicht.

Nach dem Brennen mounte ich die DVD. Ich mache die Prüfsumme ab der Datei auf
der DVD.

genau das wollte ich damit vorschlagen, ich dachte, du nimmst die
md5sum vom Image oder vom Device.

Das Eject mache ich am Ende des Backups, WENN es erfolgreich war.
Würde ein eject + Mount e.v. das Problem lösen?

irgendwo hatte ich gelesen, dass ohne eject noch Daten im Cache
bleiben können, die den Fehler begünstigen.

Hast du mir genauere Infos über den eadahead Bug?

leider auch nur das, was Google mit "readahead bug" findet.

Tritt dieses Problem wirklich nur bei der letzten Datei auf?
Falls ja, könnte ich einfach eine 2. "dummy" Datei auf die DVD Brennen.

Genaugenommen hat es nichts mit Dateien zu tun, sondern direkt
mit den Sektoren auf der DVD, aber der Effekt ist der gleiche. Eine
Dummy-Datei müsste eigentlich helfen. Einen ähnlichen Effekt
sollte auch die "-pad" Option beim Brennen haben.

[mario m]

nur zur Info:
Ich starte den Job nun aus Cron indem ich per SSH auf den eingenen Server verbinde... (Ja, es ist absolut doof, aber es geht )

Code: Alles auswählen

00 23 * * *     root    /etc/backup/backup.sh 
00 21 * * *     root    ssh -i /root/ssh_backup/ssh-rsa root@127.0.0.1 /etc/backup/backup.sh

Falls jemand weiss wiso dies so ist, es würde mich noch immer interessieren.
@cosmac: danke auf jeden fall

[bse]

sieht fast so aus, als würde es irgendwie mit dem environment zusammenhängen. Vielleicht irgendwas in der ~/.bash_profile?

[mario m]

An ein solches Problem habe ich auch schon gedacht. Allerdings habe ich nichts gefunden, was ein solches verhalten erklären könnte.

Code: Alles auswählen

cat .profile
# ~/.profile: executed by Bourne-compatible login shells.

if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi
mesg n

und die .bashrc:

Code: Alles auswählen

# ~/.bashrc: executed by bash(1) for non-login shells.

export PS1='\h:\w\$ '
umask 022

# You may uncomment the following lines if you want `ls' to be colorized:
# export LS_OPTIONS='--color=auto'
# eval "`dircolors`"
# alias ls='ls $LS_OPTIONS'
# alias ll='ls $LS_OPTIONS -l'
# alias l='ls $LS_OPTIONS -lA'
#
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'

Gruss Mario

[malteklein]

Hallo,

bin zufaellig auf dein Thema gestossen.

Code: Alles auswählen

Apr  1 22:45:06 localhost kernel: attempt to access beyond end of device
Apr  1 22:45:06 localhost kernel: hdc: rw=0, want=3940404, limit=3940032

Hatte zwar noch keine solche Fehlermeldung ,aber heisst sie nicht einfach, dass die DVD zu klein ist?

Was war nun der Fehler? Wieso geht es mit manuellem Ausfuehren, mit Cron aber nicht?

[mario m]

Hallo

Hatte zwar noch keine solche Fehlermeldung ,aber heisst sie nicht einfach, dass die DVD zu klein ist?

Nein, die Datei war ca 2.5 GB gross. Dies kann ich als Fehler ausschliessen.

Was war nun der Fehler? Wieso geht es mit manuellem Ausfuehren, mit Cron aber nicht?

Ich weiss es leider noch immer nicht. Es muss am envoirement liegen, ich kanns mir aber nicht erklären.

Mario