Results 1 to 6 of 6

Thread: amdump crashes with error: chunker: critical (fatal): errors processing config file

  1. #1

    Unhappy amdump crashes with error: chunker: critical (fatal): errors processing config file

    amdump crashes now every night with this error in /var/log/amanda/chunker.DATE.debug:
    chunker: critical (fatal): errors processing config file "/etc/amanda/DailyBackup/amanda.conf"
    Nothing further than that. The process dies.
    I have to run amcleanup and amflush after that.

    This has been my config file for years now.
    Running on CentOS 5.1 x86_64.
    Upgraded to 2.6.0p1 a couple of weeks ago and to 2.6.0p2 last week, downloaded RPMs for RHEL from zmanda.
    The errors started just before the upgrade to 2.6.0p2, and that's why I upgraded, hoping they'll go away.

    ANY HELP WOULD BE GREAT!!!

    Here's my amanda.conf:


    org "DailyBackup" # your organization name for reports
    mailto "########@###########.###" # space separated list of operators at your site
    dumpuser "amandabackup" # the user to run dumps under
    inparallel 5 # maximum dumpers that will run in parallel (max 63)
    # this maximum can be increased at compile-time,
    # modifying MAX_DUMPERS in server-src/driverio.h
    dumporder "SSss" # specify the priority order of each dumper
    # s -> smallest size
    # S -> biggest size
    # t -> smallest time
    # T -> biggest time
    # b -> smallest bandwitdh
    # B -> biggest bandwitdh
    # try "BTBTBTBTBTBT" if you are not holding
    # disk constrained
    taperalgo largestfit
    netusage 125 KBps # maximum net bandwidth for Amanda, in KB per sec
    dumpcycle 11 days # the number of days in the normal dump cycle
    runspercycle 7 # the number of amdump runs in dumpcycle days
    tapecycle 15 tapes # the number of tapes in rotation

    ### ### ###
    # WARNING: don't use `inf' for tapecycle, it's broken!
    ### ### ###

    bumpsize 30 Mb # minimum savings (threshold) to bump level 1 -> 2
    bumpdays 1 # minimum days at each level
    bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
    etimeout -30000 # total number of seconds for estimates.
    dtimeout 15000 # number of idle seconds before a dump is aborted.
    ctimeout 1999 # maximum number of seconds that amcheck waits
    # for each client host

    tapebufs 20
    # A positive integer telling taper how many 32k buffers to allocate.
    # WARNING! If this is set too high, taper will not be able to allocate
    # the memory and will die. The default is 20 (640k).


    ###runtapes 1 # number of tapes to be used in a single run of amdump
    #tpchanger "chg-manual" # the tape-changer glue script

    ###tapedev "/dev/nst0" # the no-rewind tape device to be used
    ###rawtapedev "/dev/null" # the raw device to be used (ftape only)

    #changerfile "/var/lib/amanda/DailyBackup/changer"
    #changerfile "/var/lib/amanda/DailyBackup/changer-status"
    #changerfile "/usr/local/etc/amanda/DailyBackup/changer.conf"
    #changerdev "/dev/null"

    runtapes 1 # number of tapes to be used in a single run of amdump
    tapetype VIRTUAL-TAPE-ON-HARD-DRIVE # what kind of tape it is (see tapetypes below)
    tpchanger "chg-disk"
    changerfile "/etc/amanda/DailyBackup/changer"
    tapedev "file:/DailyBackup"


    maxdumpsize -1 # Maximum number of bytes the planner will schedule
    # for a run (default: runtapes * tape_length).

    labelstr "^DailyBackup[0-9][0-9]*$" # label constraint regex: all tapes must match

    amrecover_do_fsf yes # amrecover will call amrestore with the
    # -f flag for faster positioning of the tape.
    amrecover_check_label yes # amrecover will call amrestore with the
    # -l flag to check the label.
    amrecover_changer "/dev/null" # amrecover will use the changer if you restore
    # from this device.

    # Specify holding disks. These are used as a temporary staging area for
    # dumps before they are written to tape and are recommended for most sites.
    # The advantages include: tape drive is more likely to operate in streaming
    # mode (which reduces tape and drive wear, reduces total dump time); multiple
    # dumps can be done in parallel (which can dramatically reduce total dump time.
    # The main disadvantage is that dumps on the holding disk need to be flushed
    # (with amflush) to tape after an operating system crash or a tape failure.
    # If no holding disks are specified then all dumps will be written directly
    # to tape. If a dump is too big to fit on the holding disk than it will be
    # written directly to tape. If more than one holding disk is specified then
    # they will all be used based on activity and available space.

    holdingdisk hd1 {
    comment "main holding disk"
    directory "/tmp/amanda_holding_disk" # where the holding disk is
    use -100 Mb # how much space can we use on it
    # a non-positive value means:
    # use all space but that value
    chunksize 1Gb # size of chunk if you want big dump to be
    # dumped on multiple files on holding disks
    # N Kb/Mb/Gb split images in chunks of size N
    # The maximum value should be
    # (MAX_FILE_SIZE - 1Mb)
    # 0 same as INT_MAX bytes
    }

    # If amanda cannot find a tape on which to store backups, it will run
    # as many backups as it can to the holding disks. In order to save
    # space for unattended backups, by default, amanda will only perform
    # incremental backups in this case, i.e., it will reserve 100% of the
    # holding disk space for the so-called degraded mode backups.
    # However, if you specify a different value for the `reserve'
    # parameter, amanda will not degrade backups if they will fit in the
    # non-reserved portion of the holding disk.

    # reserve 30 # percent
    # This means save at least 30% of the holding disk space for degraded
    # mode backups.

    autoflush no #
    # if autoflush is set to yes, then amdump will schedule all dump on
    # holding disks to be flush to tape during the run.

    # Note that, although the keyword below is infofile, it is only so for
    # historic reasons, since now it is supposed to be a directory (unless
    # you have selected some database format other than the `text' default)
    infofile "/var/lib/amanda/DailyBackup/curinfo" # database DIRECTORY
    logdir "/var/lib/amanda/DailyBackup" # log directory
    indexdir "/var/lib/amanda/DailyBackup/index" # index directory
    #tapelist "/var/lib/amanda/DailyBackup/tapelist" # list of used tapes
    # tapelist is stored, by default, in the directory that contains amanda.conf


    # tapetypes

    # Define the type of tape you use here, and use it in "tapetype"
    # above. Some typical types of tapes are included here. The tapetype
    # tells amanda how many MB will fit on the tape, how big the filemarks
    # are, and how fast the tape device is.

    # A filemark is the amount of wasted space every time a tape section
    # ends. If you run `make tapetype' in tape-src, you'll get a program
    # that generates tapetype entries, but it is slow as hell, use it only
    # if you really must and, if you do, make sure you post the data to
    # the amanda mailing list, so that others can use what you found out
    # by searching the archives.

    # For completeness Amanda should calculate the inter-record gaps too,
    # but it doesn't. For EXABYTE and DAT tapes this is ok. Anyone using
    # 9 tracks for amanda and need IRG calculations? Drop me a note if
    # so.

    # If you want amanda to print postscript paper tape labels
    # add a line after the comment in the tapetype of the form
    # lbl-templ "/path/to/postscript/template/label.ps"

    # if you want the label to go to a printer other than the default
    # for your system, you can also add a line above for a different
    # printer. (i usually add that line after the dumpuser specification)

    # dumpuser "operator" # the user to run dumps under
    # printer "mypostscript" # printer to print paper label on

    # here is an example of my definition for an EXB-8500

    # define tapetype EXB-8500 {
    # ...
    # lbl-templ "/usr/local/amanda/config/lbl.exabyte.ps"
    # }

    define tapetype SDT-11000 {
    comment "Sony SDT-11000 DDS-4 DAT drive"
    length 16000 mbytes
    speed 1889 kps # The output of amtapetype, run on 10/5/04
    filemark 100 kbytes # supposedly correct (integrated for DDS-4)
    }

    define tapetype VIRTUAL-TAPE-ON-HARD-DRIVE {
    comment "Daily Backup to virtual tapes on a hard drive (200GB each day for 15 days)"
    length 200000 mbytes
    }


    define dumptype global {
    comment "Global definitions"
    # This is quite useful for setting global parameters, so you don't have
    # to type them everywhere. All dumptype definitions in this sample file
    # do include these definitions, either directly or indirectly.
    # There's nothing special about the name `global'; if you create any
    # dumptype that does not contain the word `global' or the name of any
    # other dumptype that contains it, these definitions won't apply.
    # Note that these definitions may be overridden in other
    # dumptypes, if the redefinitions appear *after* the `global'
    # dumptype name.
    # You may want to use this for globally enabling or disabling
    # indexing, recording, etc. Some examples:
    # index yes
    # record no
    }

    define dumptype always-full {
    global
    comment "Full dump of this filesystem always"
    compress none
    priority high
    dumpcycle 0
    }

    define dumptype root-tar {
    global
    program "GNUTAR"
    comment "root partitions dumped with tar"
    compress none
    index
    exclude list "/usr/local/lib/amanda/exclude.gtar"
    priority low
    }

    define dumptype user-tar {
    root-tar
    comment "user partitions dumped with tar"
    priority medium
    }

    define dumptype high-tar {
    root-tar
    comment "partitions dumped with tar"
    priority high
    }

    define dumptype comp-root-tar {
    root-tar
    comment "Root partitions with compression"
    compress client fast
    }

    define dumptype comp-user-tar {
    user-tar
    compress client fast
    }

    define dumptype holding-disk {
    global
    comment "The master-host holding disk itself"
    holdingdisk no # do not use the holding disk
    priority medium
    }

    define dumptype comp-user {
    global
    comment "Non-root partitions on reasonably fast machines"
    compress client fast
    priority medium
    }

    define dumptype nocomp-user {
    comp-user
    comment "Non-root partitions on slow machines"
    compress none
    }

    define dumptype comp-root {
    global
    comment "Root partitions with compression"
    compress client fast
    priority low
    }

    define dumptype nocomp-root {
    comp-root
    comment "Root partitions without compression"
    compress none
    }

    define dumptype comp-high {
    global
    comment "very important partitions on fast machines"
    compress client best
    priority high
    }

    define dumptype nocomp-high {
    comp-high
    comment "very important partitions on slow machines"
    compress none
    }

    define dumptype nocomp-test {
    global
    comment "test dump without compression, no /etc/dumpdates recording"
    compress none
    record no
    priority medium
    }

    define dumptype comp-test {
    nocomp-test
    comment "test dump with compression, no /etc/dumpdates recording"
    compress client fast
    }

    # AR, 4/14/03, adding our dump types
    includefile "/L/amanda/amanda.dumptypes"

    # network interfaces
    #
    # These are referred to by the disklist file. They define the attributes
    # of the network interface that the remote machine is accessed through.
    # Notes: - netusage above defines the attributes that are used when the
    # disklist entry doesn't specify otherwise.
    # - the values below are only samples.
    # - specifying an interface does not force the traffic to pass
    # through that interface. Your OS routing tables do that. This
    # is just a mechanism to stop Amanda trashing your network.
    # Attributes are:
    # use - bandwidth above which amanda won't start
    # backups using this interface. Note that if
    # a single backup will take more than that,
    # amanda won't try to make it run slower!

    define interface local {
    comment "a local disk"
    use 1000 kbps
    }

    define interface le0 {
    comment "100 Mbps ethernet"
    use 5000 kbps
    }

    define interface le1 {
    comment "10 Mbps ethernet"
    use 400 kbps
    }

    define interface le2 {
    comment "1 Gbps ethernet"
    use 60000 kbps
    }

    define interface vpn {
    comment "VPN over T1 to XXXXX XXXX"
    use 125 kbps
    }


    # You may include other amanda configuration files, so you can share
    # dumptypes, tapetypes and interface definitions among several
    # configurations.

    #includefile "/usr/local/amanda.conf.main"

  2. #2
    Join Date
    Nov 2005
    Location
    Canada
    Posts
    1,049

    Default

    Quote Originally Posted by adoram View Post
    amdump crashes now every night with this error in /var/log/amanda/chunker.DATE.debug:
    chunker: critical (fatal): errors processing config file "/etc/amanda/DailyBackup/amanda.conf"
    That's strange, amdump should fail before starting the chunker if you have an error in the config file. Any error message in the amdump.0 log file?

    Did 'amadmin DailyBackup config' succeed?

  3. #3

    Default

    Quote Originally Posted by martineau View Post
    That's strange, amdump should fail before starting the chunker if you have an error in the config file. Any error message in the amdump.0 log file?

    Did 'amadmin DailyBackup config' succeed?
    Yes, 'amadmin DailyBackup config' succeeds without a problem.
    amdump's log file in /var/lib/amanda/DailyBackup/amdump shows no error.
    This backup is still running from last night, so I've checked the previous night's log of the WeeklyBackup and it shows, a few lines before the end (line 8130):
    ------------------------------------------------------
    driver: started chunker1 pid 28092
    driver: send-cmd time 9029.875 to chunker1: START 20080831171501
    driver: send-cmd time 9029.875 to chunker1: PORT-WRITE 01-00052 /tmp/amanda_holding_disk/20080831171501/myhost.mydomain.com._raid_most.1 myhost.mydomain.com fffffeff9ffe0f00000000 /raid/most 1 2008:8:3:22:52:24 1048576 GNUTAR 992 |;auth=BSD;compress-fast;index;exclude-file=./CVS;exclude-file=./data;exclude-file=./home;exclude-file=./http;exclude-file=./mysql;exclude-file=./Visf;exclude-file=./SysBackups;exclude-file=./Do_Not_Backup;exclude-list=/L/amanda/code-exclude.gtar;
    could not open conf file "/etc/amanda/WeeklyBackup/amanda.conf": Input/output error

    ** (process:28092): CRITICAL (recursed) **: could not open log file /usr/adm/amanda/log: No such file or directory
    aborting...
    driver: reading result from chunker1: Connection reset by peer
    driver: send-cmd time 9585.083 to dumper0: QUIT
    driver: send-cmd time 9585.083 to chunker0: QUIT
    driver: send-cmd time 9585.083 to dumper1: QUIT
    driver: send-cmd time 9585.083 to chunker1: QUIT
    writing chunker1 command: Broken pipe
    driver: send-cmd time 9585.083 to dumper2: QUIT
    driver: send-cmd time 9585.083 to chunker2: QUIT
    driver: send-cmd time 9585.085 to dumper3: QUIT
    driver: send-cmd time 9585.085 to chunker3: QUIT
    driver: send-cmd time 9585.085 to dumper4: QUIT
    driver: send-cmd time 9585.086 to taper: QUIT
    driver: chunker1 pid 28092 exited with signal 6
    driver: sending signal 1 to dumper0 pid 1705
    driver: sending signal 1 to chunker0 pid 18454
    driver: sending signal 1 to dumper2 pid 1707
    driver: sending signal 1 to chunker2 pid 18457
    driver: sending signal 1 to dumper3 pid 1708
    driver: sending signal 1 to chunker3 pid 24340
    driver: sending signal 1 to taper pid 1704
    driver: taper pid 1704 exited with signal 1
    driver: dumper0 pid 1705 exited with signal 1
    driver: dumper2 pid 1707 exited with signal 1
    driver: dumper3 pid 1708 exited with signal 1
    driver: chunker0 pid 18454 exited with signal 1
    driver: chunker2 pid 18457 exited with signal 1
    driver: chunker3 pid 24340 exited with signal 1
    amdump: end at Sun Aug 31 19:55:48 PDT 2008
    0
    0
    0
    0
    0
    0
    0
    0
    ------------------------------------------------------

    I have verified that it, too, passes: amadmin WeeklyBackup config.

    Thanks, adoram

  4. #4
    Join Date
    Nov 2005
    Location
    Canada
    Posts
    1,049

    Default

    Quote Originally Posted by adoram View Post
    driver: send-cmd time 9029.875 to chunker1: PORT-WRITE 01-00052 /tmp/amanda_holding_disk/20080831171501/myhost.mydomain.com._raid_most.1 myhost.mydomain.com fffffeff9ffe0f00000000 /raid/most 1 2008:8:3:22:52:24 1048576 GNUTAR 992 |;auth=BSD;compress-fast;index;exclude-file=./CVS;exclude-file=./data;exclude-file=./home;exclude-file=./http;exclude-file=./mysql;exclude-file=./Visf;exclude-file=./SysBackups;exclude-file=./Do_Not_Backup;exclude-list=/L/amanda/code-exclude.gtar;
    could not open conf file "/etc/amanda/WeeklyBackup/amanda.conf": Input/output error

    ** (process:28092): CRITICAL (recursed) **: could not open log file /usr/adm/amanda/log: No such file or directory
    aborting...
    Check your system log for disk error.

  5. #5

    Question

    I have checked and there are no disk errors, just this line:
    sendbackup [24342]: error [compress (24344) compress returned 1, dump (24347) /bin/tar returned 2]

    Any ideas?

    Thanks.
    ./adoram

  6. #6

    Cool

    martineau,

    Thanks for the advice.
    The error has been going on and off during the last 10 days, so I'm taking the server down now to run some disk tests.

    Thanks Again.

    ./adoram

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •