[ut3] Server seems to run as nothing is wrong, but nobodycanconnect

Tue Jan 29 13:08:32 EST 2008

Just in case you need a link to the updated binary:

http://treefort.icculus.org/ut3/ut3-bin-test.tar.bz2

Hope this helps.

-Rob

On Jan 29, 2008, at 12:25 PM, Rick Page wrote:

> Hi Matt,
> I am not sure if all of this information is really going to be  
> helpful, but here it is. I have read your post and it is very  
> informative, but I had already done those things.
>
> uname -a
> Linux server06.pagehosting4u.com 2.6.18-8.1.15.el5 #1 SMP Mon Oct  
> 22 08:32:04 EDT 2007 i686 athlon i386 GNU/Linux
>
> md5sum ut3-bin
> 1fe95c1d4067e25f7d28bdfac17e4957  ut3-bin
> I am not sure how to check the official version number of ut3-bin,  
> but it is the latest test ut3-bin file that was supplied here in  
> the list
>
> Operating System is CentOS 5
> Dual Processors - 2 x AMD Athlon XP 2600
> Memory - 2GB
> 2 Hard Drives - 2 x 80GB
>
> I have attached a zip file containing the DedicatedServer.log file  
> along with some backup log files. Also included is my UTGame.ini,  
> UTEngine.ini and my startup scripts.
>
> CPU usage when idle - around 9-10%
> Memory Usage when idle - around 11.5%
>
> I have not looked at the CPU and Memory usage while people were  
> playing online. I will need to gather that info tonight.
>
> What log files do I look at for packet loss? Is it the /var/log/ 
> messages files that are created?
>
> Thanks again for your help.
> Rick
>
> On Jan 29, 2008 10:04 AM, matt.culver <Matt.Culver at noaa.gov> wrote:
> When anyone posts troubleshooting questions can you please attach  
> the following:
>
> uname -a output
> md5sum and version of ut3-bin
> Relevant system information
> Log output from game console
> UTGame.ini
> UTEngine.ini
> Command line used for starting server.
> Other observations about cpu load, packet loss, memory usage.
>
> I think this will give everyone the information they need to  
> contribute informed input about your problem.
>
> I've been compiling a guide on how to install the linux server  
> (including services scripts) for centos and redhat:
> http://utforums.epicgames.com/showthread.php?t=599751
>
> Check your config against those steps and that might give you some  
> ideas.
>
> Matt Culver --
>
>
> Rick Page wrote:
>>
>> I have gone through everything and still can't figure out what is  
>> going on. It seems if I start the server and people do jump on it  
>> right away, it runs great. After a while the server will run idle  
>> as nobody is on it. It then seems that if it runs idle for a  
>> while, no one can connect again and I have to do a restart. Again,  
>> there is no indication that there is anything wrong. The server  
>> reports back server querys. It still shows up in the server  
>> browser. I have the -multihome=123.123.123.123. I am running a  
>> standard 32bit "normal" distro of CentOS 5. When I run cat /proc/ 
>> version from the commandline, I get this:
>> Linux version 2.6.18-8.1.15.el5 (mockbuild at builder6.centos.org)  
>> (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Mon Oct 22  
>> 08:32:04 EDT 2007
>> Can someone post a simple monitoring script to auto-restart the  
>> server?
>> Thanks.
>> Rick
>>
>> On Jan 13, 2008 11:54 AM, BasP <maillistrecipient at gothica.nl> wrote:
>> Do have multihome, but the machine is currently using only one IP  
>> and thus
>> the UT3 server is also (mutlihome is used as it's started through  
>> a generic
>> startscript that can also handle machine with multiple ips).
>> I will try if I can get any 'statistics' on which maps are the  
>> ones after
>> which I have to kill te server, and thus if there is some 'flacky'  
>> map out
>> there. New binary *of course* (other is instability all out), and
>> furthermore a 'precompiled' distro (no gentoo or shit) and not  
>> using 64bit
>> either. I am alomst positive that 99% of this lists problems would  
>> vanish if
>> ppl would use 32bit 'normal' distro's and no highly optimised thus  
>> inmensely
>> patched kernels (not to start a flamewar about this subject, I do  
>> realise
>> many people can't simply switch distro and all).
>>
>> ----- Original Message -----
>> From: "biz" <biz at baze.de>
>> To: <ut3 at icculus.org>
>> Sent: Sunday, January 13, 2008 3:20 PM
>> Subject: Re: [ut3] Server seems to run as nothing is wrong, but
>> nobodycanconnect
>>
>>
>> > On Sun, Jan 13, 2008 at 01:39:53PM +0100, BasP wrote:
>> >> I've written my own version of the PHP example from that page a  
>> while
>> >> back
>> >> and my usually full public server nicely return it's  
>> information when
>> >> players can't connect anymore (nicely telling me there's 0/12  
>> players
>> >> online). As the server usually is full during certain hours of  
>> the day, I
>> >> just restart it when it hits 0 players during those hours.
>> >
>> > Sounds weird, are you using the experimental binary and could  
>> you try to
>> > check for the mapname? I've tested this approach on multiple
>> > installations and for me its a direct indication. Perhaps another
>> > special case? Quite unstable anyways...
>> >
>> > For anyone else encountering -multihome problems, if your setup  
>> allows
>> > it - just run one vserver per IP so you can get rid of -multihome.
>> > There's only one IP per unit and the system's resources are shared
>> > dynamically to utilise available resources efficiently.
>> > Have a look at http://linux-vserver.org/
>> >
>> > -- biz
>> >
>> > ---
>> > To unsubscribe, send a blank email to ut3-unsubscribe at icculus.org
>> > Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm- 
>> cgi?64
>> >
>> >
>> >
>>
>>
>> ---
>> To unsubscribe, send a blank email to ut3-unsubscribe at icculus.org
>> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?64
>>
>>
>>
>
>
> <ut3.zip>
>
> ---
> To unsubscribe, send a blank email to ut3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?64

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/ut3/attachments/20080129/46a752b8/attachment.htm>