Ich habe ein Problem mit dem cron-Daemon:
Es soll täglich um Mitternacht ein Backup von zwei Festplattenpartitionen ausgeführt werden, dazu soll mit cron das Script rsnapshot aufgerufen werden. Dieses Skript führt ein Backup mit Hilfe von rsync durch. Es wurd durch cron auch aufgerufen, allerdings wird nur ein Ordner/ eine Partition gesichert, der zweite nicht.

Um zu verstehen was da passiert habe ich mir /var/log/messages angesehen, dort steht:Quellcode:Oct 17 00:00:01 server cron[5106]: (root) CMD (/home/######/backup_halt.sh)
Oct 17 00:00:01 server cron[5108]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Oct 17 00:00:01 server cron[5110]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly) /home/######/backup_halt.sh ist ein einfaches Shell-Script, was rsnapshot aufruft, nachher eine Datei mit der aktuellen Systemzeit im gerade angelegten Backup-Ordner erstellt und den Rechner herunterfährt. Das Shell-Script wird also korrekt aufgerufen.

Danach habe ich die Ausgabe von rsnapshot mit tee in eine Datei umgeleitet, dabei ist zu sehen, dass die Ausführung mittendrin abbricht, und zwar nicht beim Sichern einer bestimmten Datei, sondern jeweils an verschiedenen Stellen (ich habe das mehrmals hintereinander probiert).

Wenn ich das Script von Hand ausführe gibt es keine Probleme, das Backup wird korrekt durchgeführt. Trage ich in die crontab nur den Aufruf von rsnapshot ein statt mein eigenes Shell-Scropt, tritt das gleiche Problem auf.

System: Gentoo-Linux Kernel 2.6.22-gentoo-r5 auf i386, cron-Daemon ist vixie-cron-4.1-r10 aus dem Gentoo-Portage-Tree.

Hat jemand eine Ahnung, woran das liegen könnte oder gibt es Ideen, wie sich das beheben lässt?

:edit:
Mein home-Ordner ist natürlich nicht /home/######/, ich habe das nur zensiert, weil der Ordnername Rückschlüsse auf meinen Namen erlauben würde.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Ev. würde es helfen, wenn du noch dein rsnapshot und backup_halt.sh posten würdest (pastebin.org hat syntax highlighting und keine Grössenbeschränkung).

Die Datei /etc/rsnapshot.conf, einge Kommentare habe ich aber gestrichen, damit die Datei nuicht zu groß wird:
Quellcode:#################################################
# rsnapshot.conf - rsnapshot configuration file #
#################################################
#                                               #
# PLEASE BE AWARE OF THE FOLLOWING RULES:       #
#                                               #
# This file requires tabs between elements      #
#                                               #
# Directories require a trailing slash:         #
#   right: /home/                               #
#   wrong: /home                                #
#                                               #
#################################################

#######################
# CONFIG FILE VERSION #
#######################

config_version  1.2

###########################
# SNAPSHOT ROOT DIRECTORY #
###########################

# All snapshots will be stored under this root directory.
snapshot_root   /mnt/backup/

# If no_create_root is enabled, rsnapshot will not automatically create the
# snapshot_root directory. This is particularly useful if you are backing
# up to removable media, such as a FireWire drive.
#
no_create_root  1

#################################
# EXTERNAL PROGRAM DEPENDENCIES #
#################################

# LINUX USERS:   Be sure to uncomment "cmd_cp". This gives you extra features.
# EVERYONE ELSE: Leave "cmd_cp" commented out for compatibility.
#
# See the README file or the man page for more details.
#
cmd_cp          /bin/cp

# uncomment this to use the rm program instead of the built-in perl routine.
cmd_rm          /bin/rm

# rsync must be enabled for anything to work.
cmd_rsync       /usr/bin/rsync

# Uncomment this to enable remote ssh backups over rsync.
#cmd_ssh        /usr/bin/ssh

# Comment this out to disable syslog support.
cmd_logger      /usr/bin/logger

# Uncomment this to specify a path to "du" for disk usage checks.
#cmd_du         /bin/du

#########################################
#           BACKUP INTERVALS            #
# Must be unique and in ascending order #
# i.e. hourly, daily, weekly, etc.      #
#########################################

interval        backup  30

############################################
#              GLOBAL OPTIONS              #
# All are optional, with sensible defaults #
############################################

# If your version of rsync supports --link-dest, consider enable this.
# This is the best way to support special files (FIFOs, etc) cross-platform.
# The default is 0 (off).
#
link_dest       1

# Verbose level, 1 through 5.
# 1     Quiet           Print fatal errors only
# 2     Default         Print errors and warnings only
# 3     Verbose         Show equivalent shell commands being executed
# 4     Extra Verbose   Show extra verbose information
# 5     Debug mode      More than you care to know
#
verbose         4

# Same as "verbose" above, but controls the amount of data sent to the
# logfile, if one is being used. The default is 3.
loglevel        3

# If you enable this, data will be written to the file you specify. The
# amount of data written is controlled by the "loglevel" parameter.
#logfile        /var/log/rsnapshot

# The include and exclude parameters, if enabled, simply get passed directly
# to rsync. If you have multiple include/exclude patterns, put each one on a
# seperate line. Please look up the --include and --exclude options in the
# rsync man page for more details.
#
exclude         ct-CD/

# The include_file and exclude_file parameters, if enabled, simply get
# passed directly to rsync. Please look up the --include-from and
# --exclude-from options in the rsync man page for more details.
#
#include_file   /path/to/include/file
#exclude_file   /path/to/exclude/file

# Default rsync args. All rsync commands have at least these options set.
#
#rsync_short_args       -a
rsync_short_args        -av
#rsync_long_args        --delete --numeric-ids --relative --delete-excluded

###############################
### BACKUP POINTS / SCRIPTS ###
###############################

# LOCALHOST
backup  /mnt/nwdisc1/   nwdisc1/
backup  /mnt/nwdisc2/   nwdisc2/
Das Shell-Script backup_halt.shQuellcode:rsnapshot backup |tee /home/######/backupausgabe.txt
date -R |tee /mnt/backup/backup.0/._datum_
/sbin/halt

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Nur so als Tipp:
Quellcode:date -R > /mnt/backup/backup.0/._datum_

mwcollect - mein Projekt | oxlog - mein blog | happyhardcore.com Stream - gute Musik

@oxff: Ja, ist mir auch klar dass das geht. Das tee ist übrig geblieben aus der Version vom Script, die manuell ausgeführt wird, damit kann ich nämlich auch noch kontrollieren, ob die Uhr auf dem Rechner einigermaßen richtig geht.

Zum eigentlichen Problem hat keiner eine Idee?

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

bei backup.sh #!/bin/sh an den anfang?
evtl komplette pfäde zu den executables dadrin, also /usr/bin/rsnapshot (oder woauchimmer das liegt) statt einfach nur rsnapshot usw?

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Wobei das alles nicht in dieser Fehlerbeschreibung enden sollte.

Achtung: Es folgt die Beschreibung des eher mühsamen Wegs
Ich würde (viel freier Speicherplatz vorausgesetzt) mal versuchen, rsnapshot mit strace zu starten. Da sieht man ziemlich sicher, wo/wann/wieso das Programm abgebrochen hat.
Quellcode:strace -o logfile -- executable params Falls rsnapshot ein shell/python/whatever-script ist, musst du warscheinlich den Aufruf selber machen (also /usr/bin/python /usr/bin/rsnapshot oder was auch immer). Das Logfile dürfte allerdings ziemlich gross werden und falls der gesuchte Grund nicht dabei ist, musst du ev. noch -ff angeben, dann werden auch Child-Prozesse geloggt.
Edit: Interessant sind primär die letzten paar Zeilen: Hat sich das Programm sauber beendet? Gabs ein SIGNAL (ev. SIGHUP)?
Edit2: Gerade noch gesehen, dass rsnapshot in perl geschrieben ist. Ruf perl mal mit dem Parameter -W auf, dann sollte er alle Warnings ausspucken. Ev. ist da etwas sinnvolles dabei.

Die Vorschläge von caedes habe ich ausprobiert, die bringen aber leider nichts. Der Aufruf vom Script funktioniert ja auch, es wird mit dem Backup angefangen, aber das bricht mittendrin ab.

Die Vorschläge von hausi habe ich auch probiert, der Aufruf von perl mit dem Parameter -W brachte keine zusätzlichen Informationen, interessant war aber die Ausgabe von strace:Quellcode:write(1, "/usr/bin/rsync -avv --delete --n"..., 187) = 187
pipe([4, 5])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7d39708) = 10350
close(5)                                = 0
rt_sigaction(SIGINT, {SIG_IGN}, {0x80ab2d0, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {0x80ab2d0, [], 0}, 8) = 0
waitpid(10350, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 10350
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGINT, {0x80ab2d0, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x80ab2d0, [], 0}, NULL, 8) = 0
read(4, "", 4)                          = 0
close(4)                                = 0
stat64("/mnt/backup/backup.1/nwdisc2/", {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
stat64("/mnt/backup/backup.0", {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
lstat64("/mnt/nwdisc2/", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
stat64("/mnt/nwdisc2/", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
stat64("/mnt/backup/backup.1/nwdisc2/", {st_mode=S_IFDIR|0755, st_size=72, ...}) = 0
write(1, "/usr/bin/rsync -avv --delete --n"..., 187) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++ Das Programm wurde also mit SIGPIPE beendet. Leider habe ich keine Ahnung, was das bedeuten soll. Allerdings tritt das SIGPIPE auch auf, wenn man mit rsync synchronisiert und dabei das Medium voll wird. Das ist bei diesem Problem aber nicht der Fall, auf der Festplatte sind noch über 280GB frei.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Ist irgend eines deiner Backup-Sourcen / Targets auf einem speziellen Device (NTFS, NFS, SMBFS, CIFS, etc.)?
Setz dein cmd_rsync mal auf /usr/local/bin/rsync-wrapper:
Quellcode:#!/bin/bash
filename=/tmp/rsync-`date +%s`
echo "$*" >$filename
strace -o $filename.strace -- /usr/bin/rsync $@ Dann hast du unter /tmp/rsync-*{,.strace} noch ein paar zusätzliche Infos, wieso rsync gecrasht ist, sowie die genauen Optionen, wie es aufgerufen wurde.

Die Sourcen sind zwei Partitionen auf IDE-Festplatten, das Ziel ist auch eine Partition auf einer IDE-Festplatte. Also alles ganz normal.

Die genauen Optionen, mit denen rsync aufgerufen wurde sind:
Quellcode:-avv --delete --numeric-ids --relative --delete-excluded --exclude=ct-CD/ --link-dest=/mnt/backup/backup.1/nwdisc1/ /mnt/nwdisc1 /mnt/backup/backup.0/nwdisc1/ Die komplette Ausgabe von strace sind über 58MB, die poste ich hier also nicht. Man sieht aber wieder das SIGPIPE und den Fehler "broken pipe".

Eben habe ich rsync nochmal heu emerget, das hat aber auch keine Veränderung gebracht.

Mein Problem ist jetzt, dass ich mit dem Fehler absolut nichts anfangen kann, da ich die Funktion von rsync natürlich nicht bis ins Detail kenne. Eine google-Suche hat mich da auch nicht wirklich weitergebracht.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

sigpipe ist "SIGPIPE 13 Term Broken pipe: write to pipe with no readers", sprich entweder hat der remote den socket zugemacht, zb das terminal das terminal auf das rsync schreiben möchte ...

normales rsync geht?, könnte dann sein
der exit value vom rsync wäre noch interessant

--log-file=FILE
................
This is very useful if you need to debug why a connection is closing unexpectedly.

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.

Nach einigen Tagen nochmal neue Informationen: Das ist vielleicht bisher nicht so ganz klar geworden: Das rsync läuft lokal, also Quell- und Zielordner liegen auf dem selben Rechner.

Trotzdem habe ich den Vorschlag von default mal ausprobiert. Der zusätzliche Vorschlag aus der rsync-manpage:

Zitat:

Here's a example command that requests the remote side to log what is happening:
rsync -av --rsync-path="rsync --log-file=/tmp/rlog" src/ dest/

This is very useful if you need to debug why a connection is closing unexpectedly.

Die normale log-Datei vom rsync hat mir jetzt keinerlei Hinweise gegeben, ich erkenne darin ehrlich gesagt keine Unterschiede zwischen Normalfall und Fehlerfall.

Wie gesagt, wenn ich das gleiche Kommando, das in der crontab steht normal in der Konsole ausführe, gibt es keine Probleme. Normales rsync geht also.

Zitat:

der exit value vom rsync wäre noch interessant

Hier nochmal der von mir erweiterte rsync-wrapper, wie hausi ihn vorgeschlagen hat:Quellcode:#!/bin/bash
filename=/tmp/rsync-`date +%s`-$$
echo "$*" >$filename
strace -o $filename.strace -- /usr/bin/rsync --rsync-path="rsync --log-file=$filename.rsync-server" --log-file=$filename.rsync-client $@
echo $?>$filename.rsync-retval Wie schon geschrieben, das log für den Server wird ignoriert, sowohl im Fehlerfall als auch im funktionierenden Fall.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

das is der retval vom strace,
paste mal das client log

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.