[BackupPC-users] Debugging a SIGPIPE error killing my backups

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi all:

I have BackupPC 3.1.0beta0 running on Centos 4.4.

Here is what the logs are showing me:

  2007-10-25 07:00:04 full backup started for directory /etc
  2007-10-25 07:00:17 full backup started for directory /var/bak
  2007-10-25 07:00:17 full backup started for directory /var/log
  2007-10-25 10:54:00 Aborting backup up after signal PIPE
  2007-10-25 10:54:01 Got fatal error during xfer (aborted by signal=PIPE)
  2007-10-25 10:54:01 Saved partial dump 0
  2007-10-25 11:27:41 full backup started for directory /etc
  2007-10-25 11:27:59 full backup started for directory /var/bak
  2007-10-25 11:27:59 full backup started for directory /var/log
  2007-10-25 13:13:51 full backup started for directory /usr/local
  2007-10-25 13:13:52 Got fatal error during xfer (No files dumped for
  share /var/bak)
  2007-10-25 13:13:57 Backup aborted (No files dumped for share
  /var/bak)
  2007-10-25 13:13:57 Saved partial dump 0
  2007-10-25 13:35:48 full backup started for directory /etc
  2007-10-25 13:36:01 full backup started for directory /var/bak
  2007-10-25 13:36:01 full backup started for directory /var/log
  2007-10-25 17:29:24 Aborting backup up after signal PIPE
  2007-10-25 17:29:25 Got fatal error during xfer (aborted by signal=PIPE)
  2007-10-25 17:29:26 Saved partial dump 0

Other than running BackupPC_dump manually, is there a way to get
further debug info on this? This could run for well over 4 hours and
there was a warning about running BackupPC_dump past the point where
it starts since you don't want to have two of the running at the same
time.

I increased the verbosity to 3 to get some additional info in the xfer
logs. Does this look familiar to anybody?

    create d 755       4/3        4096 cups
  cups/error_log got digests 63fb87a9fb6e1f685500c82fd0fb16c8 vs
  63fb87a9fb6e1f685500c82fd0fb16c8
    same     600       0/3         529 cups/error_log
  cups/error_log.1 got digests 2a6cc9c7d472f73a8f9e00751fe4560f vs
  2a6cc9c7d472f73a8f9e00751fe4560f
    same     600       0/3         594 cups/error_log.1
  cups/error_log.2 got digests 400ac3344b5ec3f43cae660d11443cdf vs
  400ac3344b5ec3f43cae660d11443cdf
    same     600       0/3         594 cups/error_log.2
  cups/error_log.3 got digests 9685a7939a24f6731f46ef35c7527c13 vs
  9685a7939a24f6731f46ef35c7527c13
    same     600       0/3         594 cups/error_log.3
  cups/error_log.4 got digests 856b4c9eef8eeb9906a7ec9f738761d1 vs
  856b4c9eef8eeb9906a7ec9f738761d1
    same     600       0/3         594 cups/error_log.4
  dmesg got digests df4613c9b4853e39fd2a686e577d179e vs
  df4613c9b4853e39fd2a686e577d179e
    same     644       0/0       16246 dmesg
    create d 700       0/0        4096 httpd
  lastlog got digests fdb1c560d9ba822ab4ffa635d4b5f67f vs
  fdb1c560d9ba822ab4ffa635d4b5f67f
    create   400       0/0       65700 lastlog
  Can't write 33932 bytes to socket
  Sending csums, cnt = 16, phase = 1
  Read EOF: Connection reset by peer
  Tried again: got 0 bytes
  finish: removing in-process file ldap
  Child is aborting
  Done: 20 files, 562983 bytes
  Got fatal error during xfer (aborted by signal=PIPE)
  Backup aborted by user signal

If I am reading this right, the last file handled before the signal is
/var/log/lastlog which is << 2GB (65K approx). When the signal occurs,
I guess /var/log/ldap is the file in progress.

The ldap file is 22GB in size:

  [rouilj@ops02 log]$ ls -l ldap 
  -rw-------  1 root root 22978928497 Oct 25 18:46 ldap

Could the size be the issue?

I have:

   $Conf{ClientTimeout} = 72000;

which is 20 hours and the sigpipe is occurring before then.

We have large file support in the perl I use:

perl -V | grep file shows:

      config_args='-des -Doptimize=-O2 -g -pipe -m32 -march=i386
  -mtune=pentium4 -Dversion=5.8.5 -Dmyhostname=localhost
  -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat,
  Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
  -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads
  -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db
  -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
  -Dinstallusrbinperl -Ubincompat5005 -Uversiononly
  -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.4 5.8.3 5.8.2 5.8.1
  5.8.0'
      useperlio=define d_sfio=undef uselargefiles=define usesocks=undef

Other info:

  Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
    Platform:
      osname=linux, osvers=2.6.9-42.elsmp,
  archname=i386-linux-thread-multi
      uname='linux build-i386 2.6.9-42.elsmp #1 smp sat aug 12 09:39:11
  cdt 2006 
  i686 i686 i386 gnulinux '

The server and client are on a local 100BT lan.

Anybody got any ideas?

Also is there a way to tail the xfer logs in realtime while the daemon
is controling the backup? So I don't have to wait for the backup to
finish?

Thanks for your help.

-- 
				-- rouilj

John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111