The UTMP file in the security database came from the upgrade script. For some reason the drop of that table failed when I upgraded the database security file from 1.5 per the release notes it must not have dropped that UTMP table. Thank goodness it failed or I would probably still be trying to figure this problem out. That was the only clue that helped my figure out the threading issue that you referenced.

Thanks to everyones input. I have changed my backup scheduling service to wait for each gbak process to finish before running the next one and that should solve these problems.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 05:03 AM 17/03/2009, Matt Nielsen wrote:
> >That is correct.
> >
> >--- In firebird-support@yahoogroups.com, Dimitry Sibiryakov <sd@> wrote:
> >>
> >> > Along that line my backup scheduler kicks off all the backups at once, meaning if I have 5 databases they all get shelled off at once including the security database. I wonder if there is a thread safty issue and part of the backup file is getting corrupted by another DB's backup such as the security datase somehow data flowing into backup file.
> >>
> >> You are right, this is suspicious.
> >> Let me clarify: you do all backups at the same time, using services,
> >> right? And you use superserver, so all backup threads share the same
> >> address space.
>
> See: http://tracker.firebirdsql.org/browse/CORE-1982
>
> It affects all released "2.anything" except 2.0.5; fixed in forthcoming 2.1.2 and 2.5 Beta 1.
>
> (Can't see a table UTMP in security2.fdb on a connected Superserver under Fb 2.0.5, though...is this a private modification? Do you see it only when you restore under the Fb 2.5 Alpha? If so, and it's not of your doing, it seems worth asking about in firebird-devel.)
>
> FWIW, IBObjects never touches the security database other than via API calls.
>
> ./heLen
>