description: Hi there,

I originally posted this issue on the firebird-support group:
http://tech.groups.yahoo.com/group/firebird-support/message/93202

The issue today remains unresolved, although some conflict with the anti-virus software might be the most plausible explanation so far. (Maybe some DLLs got updated or something)

Here is the original description:

Our Classic Server stopped working overnight and we had to switch to Super Server to get it to work. Switching back to Classic Server brought up the same problems.

Symptoms:
* We've been running Classic Server for a long period of time without any real problems.

* No problems on Monday, but the next day nobody could get into the Firebird database via ODBC. We tested with isql and same result. When I used a local connection string (filepath) I was able to get access to the Firebird database. (Normally we would use the hostname:<local path> connection string)

* We restarted the server (twice).

* We did telnets from one other computer to the firebird server (port 3050) and that worked fine.

* No Microsoft updates. No event log errors. We shut down the virus program, but that made no difference.

* Evaluation of Firebird log file (see below) lead us to believe the errors were related to the socket layer (SO_KEEPALIVE, SO_NODELAY and inet errors).

Versions:
On Monday they were running version 2.0.1.12855
On Tuesday we installed 2.0.3.12981 (same problems)
ODBC 1.2.0.69 (same problem with isql though)
Win 5.2.3790

Workaround:
We found a suggestion on a Spanish (!) website suggesting to run Firebird in Super Server mode (I can't quite remember how we got to that website though, as we were quite busy at the time <grin>). That worked. Switching back to Classic Server however gave the same problems. That particular customer has a multi-core CPU so it would definitely be nice if we could somehow run it in Classic Server mode again.

Our guess:
Maybe an update of some program updated the winsock dlls which in turn caused some problem in the socket library of the Classic Server? (Mind you we're just guessing here). Alternatively it could somehow be related to the anti-virus software (Inclusion list?!?).

If anyone is interested in running a few tests and trying to get to the bottom of it, just let me know... (Our customer works pretty much round the clock with different shifts, so I might not be able to test everything immediately, but I'll do my best)

Kind regards,
Jarno

---

NOTE:
This is only a snap shot, but the rest is all a repeat of what's
below.

SBS-01 Tue Mar 18 00:14:22 2008
INET/inet_error: read errno = 10054

SBS-01 Tue Mar 18 00:18:15 2008
INET/inet_error: read errno = 10054

SBS-01 Tue Mar 18 04:40:51 2008
inet server err: setting KEEPALIVE socket option

SBS-01 Tue Mar 18 04:40:51 2008
inet server err: setting NODELAY socket option

SBS-01 Tue Mar 18 04:40:51 2008
INET/inet_error: select in packet_receive errno = 10038

=>

Hi there,

I originally posted this issue on the firebird-support group:
http://tech.groups.yahoo.com/group/firebird-support/message/93202

The issue today remains unresolved, although some conflict with the anti-virus software might be the most plausible explanation so far. (Maybe some DLLs got updated or something)

Here is the original description:

Our Classic Server stopped working overnight and we had to switch to Super Server to get it to work. Switching back to Classic Server brought up the same problems.

Symptoms:
* We've been running Classic Server for a long period of time without any real problems.

* No problems on Monday, but the next day nobody could get into the Firebird database via ODBC. We tested with isql and same result. When I used a local connection string (filepath) I was able to get access to the Firebird database. (Normally we would use the hostname:<local path> connection string)

* We restarted the server (twice).

* We did telnets from one other computer to the firebird server (port 3050) and that worked fine.

* No Microsoft updates. No event log errors. We shut down the virus program, but that made no difference.

* Evaluation of Firebird log file (see below) lead us to believe the errors were related to the socket layer (SO_KEEPALIVE, SO_NODELAY and inet errors).

Versions:
On Monday they were running version 2.0.1.12855
On Tuesday we installed 2.0.3.12981 (same problems)
ODBC 1.2.0.69 (same problem with isql though)
Win 5.2.3790

Workaround:
We found a suggestion on a Spanish (!) website suggesting to run Firebird in Super Server mode (I can't quite remember how we got to that website though, as we were quite busy at the time <grin>). That worked. Switching back to Classic Server however gave the same problems. That particular customer has a multi-core CPU so it would definitely be nice if we could somehow run it in Classic Server mode again.

Our guess:
Maybe an update of some program updated the winsock dlls which in turn caused some problem in the socket library of the Classic Server? (Mind you we're just guessing here). Alternatively it could somehow be related to the anti-virus software (Inclusion list?!?). We don't have access to the anti-virus software, but I believe it's Trend Micro.

If anyone is interested in running a few tests and trying to get to the bottom of it, just let me know... (Our customer works pretty much round the clock with different shifts, so I might not be able to test everything immediately, but I'll do my best)

Kind regards,
Jarno

---

NOTE:
This is only a snap shot, but the rest is all a repeat of what's
below.

SBS-01 Tue Mar 18 00:14:22 2008
INET/inet_error: read errno = 10054

SBS-01 Tue Mar 18 00:18:15 2008
INET/inet_error: read errno = 10054

SBS-01 Tue Mar 18 04:40:51 2008
inet server err: setting KEEPALIVE socket option

SBS-01 Tue Mar 18 04:40:51 2008
inet server err: setting NODELAY socket option

SBS-01 Tue Mar 18 04:40:51 2008
INET/inet_error: select in packet_receive errno = 10038

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Cannot Reproduce [ 5 ]

status: Resolved [ 5 ] => Closed [ 6 ]