Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Have you seen this error message?



I have a script that runs automatically every night on my desktop
computer which contains lines of the form:

tar cvjf /tmp/backup/bostonre/backup.tbz --files-from=/tmp/backup/bostonre/list.txt

Over the last week or two, on large directories, this line has been
giving me error messages like:

    log> bzip2: Caught a SIGSEGV or SIGBUS whilst compressing.

    log>    Possible causes are (most likely first):
    log>    (1) This computer has unreliable memory or cache hardware
    log>        (a surprisingly common problem; try a different machine.)
    log>    (2) A bug in the compiler used to create this executable
    log>        (unlikely, if you didn't compile bzip2 yourself.)
    log>    (3) A real bug in bzip2 -- I hope this should never be the case.
    log>    The user's manual, Section 4.3, has more info on (1) and (2).
   
    log>    If you suspect this is a bug in bzip2, or are unsure about (1)
    log>    or (2), feel free to report it to me at: jseward at bzip.org.
    log>    Section 4.3 of the user's manual describes the info a useful
    log>    bug report should have.  If the manual is available on your
    log>    system, please try and read it before mailing me.  If you don't
    log>    have the manual or can't be bothered to read it, mail me anyway.

    log> 	Input file = (stdin), output file = (stdout)

The manual has more details about how to recompile bzip2 to see if
it's something like a compiler optomizer bug.  I didn't do that, but I
did try running the same command with an Ubuntu Breezy Live disk, and
had the same problem, which suggests it isn't Debian Unstable screwing
me up.

I also did some experiments to see if it was only one of the two disks in
the system that had the error, and this doesn't seem to be the case --
in the original script it happens mostly on the older and smaller
/home drive, but that's because that's most of what I'm backing up.
When I copied the largest directory from the smaller, older, drive to
the larger, newer one and backed it up from there, it got the same
problem.

I was about to go buy a new desktop system (the prices have come down
a lot since the last time I looked at them and decided I couldn't
afford it), but then last night for the first time in at least a week,
the backup script ran without errors.

Does anyone have a useful theory about what's going on?  Would you
dump the computer this week, or wait for some more hardware price
dropping?  This system is about 5 years old, and I don't think
spending much money on improving its hardware really makes sense.  But
if it's only the backup program that has a problem, and there's a
workaround for that (rsync doesn't seem to have any problem copying
the affected directories between the two disks), then maybe I don't
have to spend the money for a new system this month.  Is bzip2 really
that much more sensitive to flaky hardware than other programs?  And
how fast is the hardware likely to get even flakier?

-- 
Laura (mailto:lconrad at laymusic.org , http://www.laymusic.org/ )
(617) 661-8097	fax: (501) 641-5011
233 Broadway, Cambridge, MA 02139




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org