Page 1 of 1

Server issue(?): Awaiting Gamestate

Posted: Thu Dec 14, 2006 9:01 am
by chroot
Hello,

i'm running three ET-Server with ET-Version 2.60b and ETPro 3.2.6, two
of the three server have the ability for ettv. The ETTV-Version is beta13 on both servers.

The problem is now the following:
Our members play fine at the evening on the servers. And at the nextday's
evening no one can connect anymore. The connection attempts hangs at
the "awaiting gamestate" section. But this effects only occurs at the both
ettv-compatible servers, the other one without ettv support still works fine.

To make the two servers rerun able, i just wrote a shellscript which restarts
the servers in the night, but this is for my opinion only a quick and dirty
solution.

So, does any other ppl have the problem or even a solution for this
problem?

thanks in advance
regards chroot

Posted: Thu Dec 14, 2006 2:32 pm
by ReyalP
I have had a similar problem with linux ETTV servers becoming non-responsive after some time. Usually a lot more than one day.

Posted: Thu Dec 14, 2006 2:40 pm
by zinx
If you want to help us debug the problem:

When one becomes unresponsive:
  • 1) start up gdb without any arguments
    2) type "attach <pid>" where <pid> is the process id of the locked up server
    3) type "bt" and press enter until it stops giving you more
    4) type "info files" and press enter until it stops giving you more
    5) copy everything beginning with the attach (it should have a frame, then the backtrace output from "bt", then the output from "info files") and send it to us. You may have to copy as you go, since there will be a lot of output.

Posted: Thu Dec 14, 2006 2:46 pm
by ReyalP
btw, by non-responsive, I mean to connects from the outside. Clients sit for ever awaiting gamestate. The server console continues to work. You can change maps for example, but it doesn't help clients connect.

Posted: Thu Dec 14, 2006 3:01 pm
by zinx
Erh, hmm. Would have to be the select not working.

Posted: Thu Dec 14, 2006 3:29 pm
by chroot
ReyalP wrote:btw, by non-responsive, I mean to connects from the outside. Clients sit for ever awaiting gamestate. The server console continues to work. You can change maps for example, but it doesn't help clients connect.
That does not apply for me, i only see the connection attempt in the console.

ill put on the log files immediately when the error comes up.

thanks for the debugging hint.

Posted: Thu Dec 14, 2006 5:05 pm
by ReyalP
ReyalP wrote:btw, by non-responsive, I mean to connects from the outside. Clients sit for ever awaiting gamestate. The server console continues to work. You can change maps for example, but it doesn't help clients connect.
edit:
I don't recall exactly whether it is awaiting gamesate or awaiting challenge they stall at, I'll check next time it happens.

Posted: Fri Dec 15, 2006 1:42 am
by chroot
Good morning,

i just created two gnud debugging files. One of the SCREEN-Process where
the ettv.x86 runs in and one seperate for the ettv.x86 process.

ettv.x86:
http://chroot.a4d-team.de/ettv.x86.txt

screen:
http://chroot.a4d-team.de/screen.session.txt

Posted: Sat Jan 06, 2007 8:01 pm
by ReyalP
Just for historical purposes, the issue I get causes clients to get stuck awaiting gamestate, and may be related to the server running continuously for 2^31ms (about 25 days)

In general, it's a very good idea to restart your server every 2 weeks or so to avoid various issues like this.

Posted: Sun Jan 07, 2007 2:12 am
by The Necromancer
shouldn't server restart itselfs because of error? ( it is in Q3 engine source )

Posted: Sun Jan 07, 2007 6:12 pm
by ReyalP
The Necromancer wrote:shouldn't server restart itselfs because of error? ( it is in Q3 engine source )
It appears that the server just does vstr nextmap at 2^31. This leaves quite a few ways for things to go wrong. I'm not 100% certain the issue I encountered is caused by this, but I know of another bug (rcon stops working) which is definitely caused by this. There is a good chance that there are more.

Posted: Mon Jan 08, 2007 6:42 am
by The Necromancer
but it kills itselfs before doing it with sv_shutdown

Posted: Mon Jan 08, 2007 1:27 pm
by ReyalP
The Necromancer wrote:but it kills itselfs before doing it with sv_shutdown
SV_Shutdown doesn't do what you think it does.