At 10:22 PM 16/02/2006, you wrote:

>--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
> > 1. Exactly what does "hang" mean in this context?
>I mean that all the C application running on the same machine that are
>connected to the database stuck without any feedback. All the
>application, not yet connected, trying connecting to the database for
>a simple select statement answer with the following messages:
>-DB_Attach
>-Unable to complete network request to host "localhost".
>-Failed to establish a connection.
>-Select_SQL/start_trs
>-invalid database handle (no active connection)
>-Select_SQL/commit
>-invalid transaction handle (expecting explicit transaction start)
>-DB_Detach/detach_db
>-invalid database handle (no active connection)

Have you checked to see whether the server process has crashed?

>
>
> > 2. What do you see in the firebird.log?
>
>I'll have the log soon. Unfortunately the production machine is in a
>remote area and to have the info it takes time. I 'll post it ASAP

It is rather pointless trying to troubleshoot this problem without the log.

>Yes I'm. on RH 9 is running SuperServer 1.5.1-nptl. I double checked
>and also in RH9 there is an old nptl version
>
> > 6. However, there could be a compatibility issue for any clients
> > trying to connect with a mismatched client library.
>
>The client are mainly application running on the same server that use
>the libfbclient.so.1.5.3.

That's OK.

>But there are windows clients running the gds32.dll coming from
>Interbase 6.0. But these client are seldomly used.

That's not OK and it could cause the problems you describe - every
2-3 days, I think you mentioned?

>Never touched the firebird.conf file, always used the default
>installation settings. The trouble happens in 2 different places on
>separate server in different local network with the same config and no
>firewall installed.
>
>Do you think that inserting the LD_ASSUME_KERNEL=2.2.5 variable as
>suggested in the Release note could help ?

That could help, *provided* you install the regular x86 version, not
the NPTL version. There was *something* about NPTL on some hardware
causing process caches to become corrupt by writing them out
prematurely. I don't recall the details now but you could try
googling for it. Include Fedora Core 4 in the search, because I seem
to recall that as the context of an earlier report of a similar problem.

./heLen