At 05:06 AM 28/03/2008, you wrote:

>Firebird 2.0.3.12981 had been running without incident for 3 weeks on
>a Red Hat Linux server, with typically 25 connections. At 10:33 this
>morning, one of the clients disconnected uncleanly (``Connection reset
>by peer''). As a result, ``fbguard'' caught this and restarted the server:
>
>XXX (Server) Thu Mar 27 10:33:45 2008
> INET/inet_error: read errno = 104
>
>XXX (Client) Thu Mar 27 10:33:46 2008
> /opt/firebird/bin/fbguard: bin/fbserver terminated abnormally (-1)
>
>XXX (Client) Thu Mar 27 10:33:46 2008
> /opt/firebird/bin/fbguard: guardian starting bin/fbserver
>
>When the guardian restarted the server, ``fbserver'' was no longer
>listening on the canonical port of 3050. In this case, it was
>listening on port 58798. A check of ``netstat'' showed that both the
>standard port of 3050 was still listening as well as the ``new'' port
>of 58798.
>
>However, only connections made to port 58798 were possible. Any
>attempt to connect to port 3050 just timed out.
>
>We've made no configuration changes and have no idea of what egregious
>action may have been taken by the client to cause the abnormal
>termination of ``fbserver''.
>
>So, what caused ``fbserver'' to start listening on a port other than
>3050 after the guardian restarted it? And what can we do to prevent
>this from recurring?

The engine doesn't "port-hop" for its primary connection channel. However, random-numbered sockets are opened for the "events" channel, typically ports in this high-numbered range. Some 2.0.3 bugs exhibit as server crashes when clients disconnect while the server is in the process of delivering events (and one or other untoward things). These are fixed in the upcoming 2.0.4. Possibly Redhat's TCP/IP implementation is somehow diverting the socket requests to the open events port for the troublesome connection thread.

This would be one to put into the Tracker. It might or might not be related to events. It seems like something we should know about, if some TCP/IP transport implementations have the potential to break Firebird's layering in unexpected ways. Try to be as precise as possible about conditions when this occurred along with anything you know about your TCP/IP setup. Include as much detail as you can about the hardware and the routing plan.

./heLen

>------------------------------------
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Visit http://www.firebirdsql.org and click the Resources item
>on the main (top) menu. Try Knowledgebase and FAQ links !
>
>Also search the knowledgebases at http://www.ibphoenix.com
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Yahoo! Groups Links
>
>
>