Subject Re: Baffling gbak hangups [FIXED!]
Author Steve Friedl
Hi folks, trying to reply to my own digest-ed version:

> On Mon, Jul 05, 2010 at 11:52:21AM -0000, firebird-support@yahoogroups.com wrote:
> > ________________________________________________________________________
> > 2a. Re: Baffling gbak hangups
> > Posted by: "Leyne, Sean" Sean@... seanchk_98
> > Date: Sun Jul 4, 2010 11:08 am ((PDT))
> >
> > Steve,
> >
> > > I support some line-of-business software that uses Firebird, and out of
> > > dozens of Linux database servers running 2.0.4 Classic (64bit), *one* of them
> > > has sporadic hangups during backup.
> >
> > Please describe what you mean by "hangs"?
>
> Both the gbak and associated fb_inet_server just sit there just sits
> there without chewing any CPU time at all.
>
> > Any error messages, on console? In firebird.log?
>
> No messages of any kind that could conceivably be related. I am in
> the firebird and /var/log/messages files all the time, nothing even
> with a nearby timestamp.
>
> > Does it "hang" without end, or for a while? If "without end", what is the longest you have waited? If "a while" how long?
>
> Hmmm, I've seen them just sit there for days - let's say 3 or 4? Normally the
> backup completes in a few minutes.
>
> As a side note, when it's hung up, fb_lock_print shows *no* Firebird locks
> of any kind (backups run while the application is typically idle).
>
> > Is it "hanging" on databases which have been active during the day?
>
> All the databases are active in one form or another during the day, it's
> a function of the way the app works to touch each file. I've not found any
> pattern as to files hanging being related to anything I can find.
>
> > You might want to add a gstat command ahead of the gbak call, to output the header page stats.
> > This would let you know what the state of the database is like before you start (you could see
> > if there are any open/long running transactions)
>
> An outstanding idea!
>
> I'll retrofit my backup script to include this step before starting the
> backup itself. Perhaps this will tease out a clue...

I did an inplace "yum" update from CentOS 5.4 to 5.5, without any other
changes, and the gbak problems seem to have vanished: it's hard to believe that
the OS had something to do with it, but as they were the only customer on
that exact version, so I don't have any comparisons.

I appreciate the guidance I received here.

Steve

---
Stephen J Friedl | Security Consultant | UNIX Wizard | 714 694-0494
steve@... | Orange County, CA | Microsoft MVP | unixwiz.net