Amanda-Users

Re: /usr/lib/amanda/chg-disk:: tape_rdlabel: tape open: line 146: [: -le: unary operator expected

2007-12-06 02:31:54
Subject: Re: /usr/lib/amanda/chg-disk:: tape_rdlabel: tape open: line 146: [: -le: unary operator expected
From: Geert Uytterhoeven <geert AT linux-m68k DOT org>
To: Dennis Ortsen <dortsen AT gmail DOT com>
Date: Thu, 6 Dec 2007 08:26:39 +0100 (CET)
On Wed, 5 Dec 2007, Dennis Ortsen wrote:
> I've just hit a 100% full root filesystem (as in /  )(ouch). I managed
> to get it a bit larger (using LVM on RHEL5). After the root file
> system had space left again, I thought I could check the upcoming
> backup with AMANDA again. So I ran a "amcheck jobname -a" and got the
> following result mailed to me:
> 
> Amanda Tape Server Host Check
> -----------------------------
> Holding disk /amhold2: 95485 MB disk space available, using 92413 MB
> slot /usr/lib/amanda/chg-disk:: tape_rdlabel: tape open: line 146: [:
> -le: unary operator expected: No such file or directory
> 
>        (expecting tape DPF-03 or a new tape) Server check took 0.738 seconds
> 
> Amanda Backup Client Hosts Check
> --------------------------------
> Client check: 27 hosts checked in 0.106 seconds, 0 problems found
> 
> (brought to you by Amanda 2.5.0p2)
> 
> What does that error on lin 146 mean? I don't understand where this
> comes from. I opened /usr/lib/amanda/chg-disk and checked line 146. It
> all looks fine to me. The /bin/sh (referred to in the first line)
> exists and is executable (it's actually a symlink to /bin/bash, RedHat
> default). I've got the idea that when my root filesystem was up to
> 100% full, some kind of flag got messed up with amanda's virtual tape
> (chg-disk) settings. Is that possible? only my /usr/lib/amanda
> (binaries) and the /etc/amanda (config files and the changer* files)
> could have had a problem with that.
> 
> Is this recoverable? the server hasn't been updated, no new things
> have happened, I don't know where this comes from.

Yes, somewhere on the root file system is a file that indicates the
current changes status. Apparently it's modified in an unsafe way,
causing problems when the root file system becomes full.

I had a similar problem last week. IIRC, I fixed it by letting the
changer move to an explicit slot number:

    amtape DailySet1 slot 1

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert AT linux-m68k 
DOT org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds

<Prev in Thread] Current Thread [Next in Thread>