--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:

>
> At 07:58 PM 18/04/2007, you wrote:
> >Hi all,
> >I've a linux server with fedora 3 kernel 2.6.12;
> >firebird 1.54 NPTL 2.3.6 with no UDF implemented in db structure
> >the application is based on PHP 4.4.5
> >randomly in logs this error appears and firebird process halts
> >
> >
> >db (Server) Wed Apr 18 06:11:22 2007
> > SCH_validate -- not entered
>
> It is a thread-scheduling error *somewhere*. The server had a
> request to start a thread but for some reason it could not do so.

I

> couldn't tell why though...will perhaps be able to give you one or
> two things to check on.
>
>
> >db (Server) Wed Apr 18 06:13:22 2007
> > INET/inet_error: read errno = 88
> >
> >db (Server) Wed Apr 18 06:13:22 2007
> > INET/inet_error: send errno = 88
>
> Both of these are network errors telling you that the network

socket

> no longer exists (or never existed). It is possible that the

server

> crashed and fbguard can't restart it...or maybe you have some kind

of

> intermittent fault in the network..or someone killed the server
> process while client threads were active.
>
>
> >db (Server) Wed Apr 18 06:13:22 2007
> > Database:
> > I/O error for file "master.fdb"
> > Error while trying to write to file
> > Bad file descriptor
>
> You could tell us more. Do you ever get a good connection to this
> database? The error being reported seems to indicate that the
> database file can't be accessed. Is the client passing a proper
> connection string? I'm fairly sure we should see a fully qualified
> file path in this message.
>
> >the only solution is to kill and restart the process.
> >
> >We know there is a correspondece between SCH_VALIDATE error and UDF
> >but, as i've wrote, we don't have any UDF on this database.
>
> AFAIR, that association occurs when UDFs are not thread-safe.
>
>
> >what are the possible causes?
>
> We seem to have seen SCH_VALIDATE errors appearing before, under
> conditions where there is a mismatch between the threading model of
> the Firebird Superserver build and the threading setup on the host
> machine, albeit not usually where the NPTL build is running on a

host

> that is *supposed* to support NPTL. It's usually the other way
> around, i.e. running a non-NPTL build on a system that has NPTL

active.

>
> However, if you cannot rule out the possibility that you have a
> profile there that is forcing the system to use the old threading
> model, it would be worth checking:
>
> printenv LD_ASSUME_KERNEL
>
> If it *does* return something, and that is a lower kernel version
> than 2.6.12, it would be a clue.
>
> Sorry I can't be more help. I hope someone can.
>
> ./heLen
>

thank you very much for your answer. here are my adds to your points:
I told our IT manager to check for the structure and he told that:
1) there are no mismatchs between firebird threads model and kernel
threads model
2) we don't have any script scheduled using UDFs
3) till last week we were on a non NTPL SS and the same error occurred
4) firebird service crashes during non working period, or at least
during light working period (night, early in the morning, launch
break) and not when the system is more stressed.
5) the full path of the db is "/var/san/dati/master.fdb"
6) we typed printenv LD_ASSUME_KERNEL on shell but nothing appears

best regards