At 08:21 PM 14/02/2005 +0200, you wrote:

>* database is located on the same disk
>* It is firebird superserver 1.5.2 running on Debian
>* clients are windows and linux boxes
>* ~30 client PCs which are connecting to the server with 10 sek interval
>they are located on local network
>* connection string(something like this?):
>firebird://user:pass@.../mydb

Aaarrrrgh!!!!!!!!!!!!!!!!

>* terminal? nop
>* I use rfunc UDF
>
>check lsof output, pay attention to lines which indicates ESTABLISHED
>connection, those two PCs are switched off(even netstat shows that there
>is a connection)! Server somehow doesn't close those connections and
>craches after some time, I have to kill it with -9. I can't do a lot of
>debuggin(server is being used very intensive), but if you tell me what
>data should I collect, I can do that.

No need. The exact cause of the problem is already clear.

>btw, maybe dabase server is confused somehow because I have three
>network interfaces with same IP. But I don't think that that is a problem.

You bet it is *the* problem.

>fbserver 28371 root 0u IPv4 5828710 TCP
>*:gds_db (LISTEN)
>fbserver 28371 root 5u IPv4 6029964 TCP
>kafe.lintech.lv:gds_db->62.85.xx.xx:2857 (ESTABLISHED)
>fbserver 28371 root 7u IPv4 6055751 TCP
>kafe.lintech.lv:gds_db->62.85.xx.xx:3314 (ESTABLISHED)

>Helen Borrie wrote (twice!!):
>
> >You didn't answer this question:
> >
> > >> Do you have the database file on a mounted filesystem (Windows: share
> >or mapped drive) ?

And you do.

I hope that these server crashes are evidence that the gods are merciful.
Having concurrent - or indeed, ANY -- connections to a database through
these network mappings is Death to Databases, literally, the database can
be corrupted irrevocably. It is one of the WORST things you can do to a
Firebird database (second only to immersing the HDD in hot acidic liquid.)

Don't mess around with the wire protocol. The client uses the TCP
transport layer and it has *very good reasons* to kick up a fuss if you
start throwing mappings at it. Be hopeful that the crashes occurred before
the clients' requests had a chance to break data. The chances of repairing
this kind of corruption are exceedingly remote. I do hope you have some
good backups from the time before you started this tightrope walking.

Also, those dead connections are sitting around there, eating resources,
because the server doesn't know that it owns them.
--------------------------------------------------------------------------

Back to the drawing board....

First, establish the network node through which the service is going to
listen. This has to be the actual IP address of the host machine - no port
designation, SMB mappings, NFS addresses.

Let's suppose it is 62.85.99.0

Right, now:

1. In the hosts file (on regular Linuxen it is located in /etc/, don't
know where in Debian...) add this entry:
62.85.99.0 fbdbserver # Firebird database server

2. In /opt/firebird/aliases.conf, make this entry (it looks as if you
might already have it):
mydb = /home/firebird/fredsdatabase.fdb

3. In /opt/firebird/firebird.config, find the parameter
RemoteBindAddress. Remove the # comment marker and make the entry:
RemoteBindAddress = 62.85.99.0

(If you have a gateway card that is to be used to restrict which clients in
the LAN may access the service, and its IP address is STABLE, then use this
as the RemoteBindAddress instead.)

Next, stop the service and restart it.

Now, all clients (Linux or Win32) must connect to the server using the
SAME connection string:

fbdbserver:mydb

You still didn't answer the question about which client library your Linux
clients are using to access the database. One hopes it is libfbclient.so.

I don't know about Debian's behaviour regarding a host connecting to its
own IP address. If there is a problem with this, do not resolve it with a
mapping. You will be able to make local connections through localhost (IP
address 127.0.0.1), so make sure that it is also declared in the hosts
file. Your local connection string would then be

localhost:mydb

As a tip for future messages - would you please read this article:

http://www.catb.org/~esr/faqs/smart-questions.html

./heLen