-923 isc_attach_database: connection rejected by remote interface
Using python's kinterbase to talk to the server I am getting this error:
kinterbasdb.OperationalError: (-923, 'isc_attach_database: \n connection rejected by remote interface')
The server runs fine for after being started, then I will get a bunch of
those errors from several different applications, then it will come good
again for a while. It appears that after 24 hours or so it gets to the
stage where it can't recover.
These messages are appearing in /var/log/firebird2.5.log:
I am trying to figure out what might be causing this, but in the mean
time I will probably switch to the classic server. Can anybody give me
some hints? The server is regularly asked to do large transactions they
might take 30 to 40 seconds to complete. Oddly, when I do an lsof on
fbserver when this is happening it typically has no client connections
Re: -923 isc_attach_database: connection rejected by remote interface
On Wed, 2010-09-01 at 13:09 +1000, Russell Stuart wrote:
> Using python's kinterbase to talk to the server I am getting this error:
> kinterbasdb.OperationalError: (-923, 'isc_attach_database: \n connection rejected by remote interface')
I switched to the classic server. It all went well for a few days, then
it hit what appears to be the same problem.
This time there was no problem connecting to the server, as you might
expect given the classic version was being used. By every connection
had frozen, meaning it appeared the client was waiting for a response
from the server that never came.
I made a guess at the oldest fb_inet_server being the problem. An lsof
of it showed it had a active connection to port 3050. I killed the
process that held that connection open (an apache2 instance). Then the
lsof showed the connection had gone to a CLOSE_WAIT state, but the
fb_inet_server didn't exit and all other fb_inet_server instances
remained frozen. So then I killed it with SIGTERM. No difference - it
didn't exit, and all other fb_inet_server's remained frozen. So then I
reluctantly killed it with SIGKILL. It died, and all other
fb_inet_server servers then unblocked and went on their merry way.
I looks to me like 2.5 has a locking problem - one that can take down
all instances of a classic server. It smells like the same problem
that afflicted the super server, the only difference being that once the
super sever deadlocked it didn't do accept()'s to new connections so
I can't reproduce this problem, but it does happen fairly regularly in
the super server (at least once per day). I am willing to go to a bit
of effort to find it, if someone wants to tell me what to do.
This SF.net Dev2Dev email is sponsored by: