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=<a href="http://123.123.123.123">123.123.123.123</a>. I am running a standard 32bit "normal" distro of CentOS 5. When I run cat /proc/version from the commandline, I get this:<br>
Linux version 2.6.18-8.1.15.el5 (<a href="mailto:mockbuild@builder6.centos.org">mockbuild@builder6.centos.org</a>) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #1 SMP Mon Oct 22 08:32:04 EDT 2007<br>Can someone post a simple monitoring script to auto-restart the server?<br>
Thanks.<br>Rick<br><br><div class="gmail_quote">On Jan 13, 2008 11:54 AM, BasP <<a href="mailto:maillistrecipient@gothica.nl">maillistrecipient@gothica.nl</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Do have multihome, but the machine is currently using only one IP and thus<br>the UT3 server is also (mutlihome is used as it's started through a generic<br>startscript that can also handle machine with multiple ips).<br>
I will try if I can get any 'statistics' on which maps are the ones after<br>which I have to kill te server, and thus if there is some 'flacky' map out<br>there. New binary *of course* (other is instability all out), and<br>
furthermore a 'precompiled' distro (no gentoo or shit) and not using 64bit<br>either. I am alomst positive that 99% of this lists problems would vanish if<br>ppl would use 32bit 'normal' distro's and no highly optimised thus inmensely<br>
patched kernels (not to start a flamewar about this subject, I do realise<br>many people can't simply switch distro and all).<br><div class="Ih2E3d"><br>----- Original Message -----<br>From: "biz" <<a href="mailto:biz@baze.de">biz@baze.de</a>><br>
To: <<a href="mailto:ut3@icculus.org">ut3@icculus.org</a>><br></div><div class="Ih2E3d">Sent: Sunday, January 13, 2008 3:20 PM<br>Subject: Re: [ut3] Server seems to run as nothing is wrong, but<br>nobodycanconnect<br>
<br><br></div><div><div></div><div class="Wj3C7c">> On Sun, Jan 13, 2008 at 01:39:53PM +0100, BasP wrote:<br>>> I've written my own version of the PHP example from that page a while<br>>> back<br>>> and my usually full public server nicely return it's information when<br>
>> players can't connect anymore (nicely telling me there's 0/12 players<br>>> online). As the server usually is full during certain hours of the day, I<br>>> just restart it when it hits 0 players during those hours.<br>
><br>> Sounds weird, are you using the experimental binary and could you try to<br>> check for the mapname? I've tested this approach on multiple<br>> installations and for me its a direct indication. Perhaps another<br>
> special case? Quite unstable anyways...<br>><br>> For anyone else encountering -multihome problems, if your setup allows<br>> it - just run one vserver per IP so you can get rid of -multihome.<br>> There's only one IP per unit and the system's resources are shared<br>
> dynamically to utilise available resources efficiently.<br>> Have a look at <a href="http://linux-vserver.org/" target="_blank">http://linux-vserver.org/</a><br>><br>> -- biz<br>><br>> ---<br>> To unsubscribe, send a blank email to <a href="mailto:ut3-unsubscribe@icculus.org">ut3-unsubscribe@icculus.org</a><br>
> Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?64" target="_blank">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?64</a><br>><br>><br>><br><br><br>---<br>To unsubscribe, send a blank email to <a href="mailto:ut3-unsubscribe@icculus.org">ut3-unsubscribe@icculus.org</a><br>
Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?64" target="_blank">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?64</a><br><br><br></div></div></blockquote></div><br>