Subject 1.5.1 CS for Linux with xinetd
Author David Montgomery
Hi everyone,

Until recently, we had been running FB 1.5.1 on a Windows machine, but
now we're running in a Linux environment.

One puzzling behavior I've encountered is related to leaving
connections to the server open unintentionally (which I discovered
from a bug in one of my apps) which seems to create an entry in 'ps
-aux' like:

fbdata 10051 0.0 0.6 89108 7088 ? S 14:12 0:00
fb_inet_server

After a while my buggy application managed to get xinetd to restart
the gds_db service for too many open connections. I would expect
xinetd to act this way, BUT...when xinetd allows client connections
again, ALL of the previous connections remain open on the server (i.e.
the same 'fb_inet_server' entries remain in the process list). I
would expect the existing connetions to get dropped/killed when this
happens.

Does anyone have any insight into how the server should behave with
abaondoned connections? For the life of me, I can't remember if
Firebird automatically cleans these up after a certain period of
inactivity.

Another question of interest for me: does anyone have any metric of
the maximum total number of concurrent connections are supported by CS
in Linux.

Best Regards,

David Montgomery