Subject | Unexpected for me or really unexpected? |
---|---|
Author | Alexander V.Nevsky |
Post date | 2001-08-17T12:40:06Z |
Hi All.
We need every night terminate user's access to make statistical
calculations, sweep and backup (I know that last I can do on the fly,
critical are first two actions). Is there save way to break client
connections by server software? I thought I know answer - we made
gfix -shut -force 0 and unload xinetd.
Yesterday we got corruption of statistical tables, and so
serious that we were forced to restore database from previous gbk.
We made some experiments today and we have some questions about
shutdown and behavior of server processes.
About gfix -shut.
Client side.
Remote client performing query get SQLCODE = -902 database shutdown,
attached inactive client don't feel database shutdown while don't
try to make something. It is expected, unexpected is that when
client tries to make activity it get SQL error code = -204 -
Table unknown. When SYSDBA make shutdown, connected database creater
lost connect (expected) but can at once establish new one
(unexpected).
Server side.
gds_inet_server processes remains in ESTABLISHED state until client
don't explicitly disconnect. Unexpected.
Question: are my "unexpected" for me only or it is really wrong
behavior?
About unload xinetd.
Client trying to make activity get
SQLCODE = -902 Unable to complete network request to host "host".
-Error reading data from the connection.
gds_inet_server processes are sent signal 9 and dies, but remains
socket connections
tcp gds_db FIN_WAIT2
(I don't know is it normal or not) that USUALLY disappear after
timeout. Yesterday this "usually" does not happen (fully unexpected):
xinetd[15623]: Sending signal 9 to gds_db server 11203
xinetd[15623]: Sending signal 9 to gds_db server 11067
xinetd[15623]: Exiting...
xinetd: xinetd shutdown succeeded
<place for calculations and maintenance actions>
xinetd[8262]: bind failed (Address already in use (errno = 98)).
service= gds_db
xinetd[8262]: xinetd Version 2.1.8.8p2 started with
xinetd[8262]: libwrap
xinetd[8262]: options compiled in.
xinetd[8262]: Started working: 4 available services
xinetd: xinetd startup succeeded
Calculations (isql script of SP calls) failed with
internal gds software consistency check
(cannot find record back version (291))
internal gds software consistency check
(can't continue after bugcheck)
Question: Can somebody here explain me that I'm an idiot
and point me how to safely do what I want or there is
really some bug in Linux/FB?
Thanks for your attention. Alexander V.Nevsky
We need every night terminate user's access to make statistical
calculations, sweep and backup (I know that last I can do on the fly,
critical are first two actions). Is there save way to break client
connections by server software? I thought I know answer - we made
gfix -shut -force 0 and unload xinetd.
Yesterday we got corruption of statistical tables, and so
serious that we were forced to restore database from previous gbk.
We made some experiments today and we have some questions about
shutdown and behavior of server processes.
About gfix -shut.
Client side.
Remote client performing query get SQLCODE = -902 database shutdown,
attached inactive client don't feel database shutdown while don't
try to make something. It is expected, unexpected is that when
client tries to make activity it get SQL error code = -204 -
Table unknown. When SYSDBA make shutdown, connected database creater
lost connect (expected) but can at once establish new one
(unexpected).
Server side.
gds_inet_server processes remains in ESTABLISHED state until client
don't explicitly disconnect. Unexpected.
Question: are my "unexpected" for me only or it is really wrong
behavior?
About unload xinetd.
Client trying to make activity get
SQLCODE = -902 Unable to complete network request to host "host".
-Error reading data from the connection.
gds_inet_server processes are sent signal 9 and dies, but remains
socket connections
tcp gds_db FIN_WAIT2
(I don't know is it normal or not) that USUALLY disappear after
timeout. Yesterday this "usually" does not happen (fully unexpected):
xinetd[15623]: Sending signal 9 to gds_db server 11203
xinetd[15623]: Sending signal 9 to gds_db server 11067
xinetd[15623]: Exiting...
xinetd: xinetd shutdown succeeded
<place for calculations and maintenance actions>
xinetd[8262]: bind failed (Address already in use (errno = 98)).
service= gds_db
xinetd[8262]: xinetd Version 2.1.8.8p2 started with
xinetd[8262]: libwrap
xinetd[8262]: options compiled in.
xinetd[8262]: Started working: 4 available services
xinetd: xinetd startup succeeded
Calculations (isql script of SP calls) failed with
internal gds software consistency check
(cannot find record back version (291))
internal gds software consistency check
(can't continue after bugcheck)
Question: Can somebody here explain me that I'm an idiot
and point me how to safely do what I want or there is
really some bug in Linux/FB?
Thanks for your attention. Alexander V.Nevsky