Server issue(?): Awaiting Gamestate

[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

[ReyalP]

I have had a similar problem with linux ETTV servers becoming non-responsive after some time. Usually a lot more than one day.

[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.

[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.

[zinx]

Erh, hmm. Would have to be the select not working.

[chroot]

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.

[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.

edit:
I don't recall exactly whether it is awaiting gamesate or awaiting challenge they stall at, I'll check next time it happens.

[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

[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.

[The Necromancer]

shouldn't server restart itselfs because of error? ( it is in Q3 engine source )

[ReyalP]

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.

[The Necromancer]

but it kills itselfs before doing it with sv_shutdown

[ReyalP]

but it kills itselfs before doing it with sv_shutdown

SV_Shutdown doesn't do what you think it does.