At 10:38 PM 22/01/2004 +0000, you wrote:

>--- In firebird-support@yahoogroups.com, Milan Babuskov <albis@e...>
>wrote:
>
> > Try connecting with isql to remote server, and tell us what happens.
>
>when you say coincidences!
>
>The server just stopped answering.
>
>If I try to connect, WISQL hangs and must be killed.
>
>Instead, I can connect with a SSH client.
>
>What is new is that also the local (on the server) isql hangs when
>launched from the SSH client, with the command
>
>/opt/interbase/bin/isql -u "SYSDBA"

>-p "masterkey"

The short form of "password" for isql is -pas

>-x /root/torino/auto.gdb >test.1

You need to provide a path for the output file that is in a directory that
you have permissions to write to.

>I have tried different databases, and the result is the same.

A better test would be to try to just connect to the database with isql,
not to attempt a command-line operation that you may not have permissions for.

Note also that Superserver does not permit a local connection that doesn't
use the network protocol. Did you apply the "localhost:" prefix to your
path in SSH as well?

>"ps -ef" contains the following rows
>
>root 3181 1 0 Jan21 ? 00:00:00 /opt/interbase/bin/ibguard -f
>root 3182 3181 26 Jan21 ? 07:51:25 /opt/interbase/bin/ibserver

That tells you that ibguard is running and ibserver is listening. The
start time differences suggest that ibserver has been terminated at some
point (possibly a lot of times) and the last time guardian restarted it was
nearly 8 hours after the initial start.

>"tail interbase.log" gives
>
>xxx.xxx.xx (Server) Thu Jan 22 16:48:11 2004
> INET/inet_error: read errno = 104
>
>xxx.xxx.xx (Server) Thu Jan 22 22:17:42 2004
> INET/inet_error: read errno = 104
>
>xxx.xxx.xx (Server) Thu Jan 22 22:18:15 2004
> INET/inet_error: send errno = 32

These are network errors. AFAIR, the first two refer to lost client
connections and the last one means that the server has finally closed the
lost connection.

>After reboot, the FB service started normally.
>
>Any help ?

Your main thing has to be to find out why connections are being refused or
dropped.

Check that:
-- the server's hostname and IP address are properly identified in
/etc/hosts and also verify that you don't have some other process in the
network that is messing with network addresses.
-- the server's hostname and IP address are properly identified in the
HOSTS file of your Windows clients
-- your Windows clients are using the proper versions of the Firebird
client library and isql. If you are using WISQL I am suspicious. This is
an IB 5 utility and it would be no surprise if it crashes when mixed with
the wrong versions of isql, client, etc.

Try to simplify your connection tests. Start by pinging the server.

Then just try to connect to a database without "doing something" as well.

Make a point of checking the switch abbreviations for the command-line
utilities. They are NOT consistent with one another.

/heLen