Re: [hlds_linux] Steam UserID Ticket Problems

[Bruno Garcia]

This might not sound very helpful, but maybe passing -ip -port and
-clientport parameters will help in the networking process (For all your
servers)

On Mon, Dec 12, 2011 at 10:53 PM, PAL-18  wrote:

> I narrowed down the problem but i still dont know how to fix it.
>
> It's definately not my server box because i can host other servers (Garrys
> Mod) and the error doesnt happen there.  It's just this particular mod.
>  How can a mod cause this type of connection problem?
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Steam UserID Ticket Problems

[PAL-18]

I narrowed down the problem but i still dont know how to fix it.

It's definately not my server box because i can host other servers (Garrys Mod) 
and the error doesnt happen there.  It's just this particular mod.  How can a 
mod cause this type of connection problem?


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

[hlds_linux] Wanted: bug reports for clients dropping due to auth failures

[Fletcher Dunn]

I'm posting this again to make sure everybody knows what you can do to help us 
fix the problem where server shed batched of clients at a time, citing auth 
failures.  We have yet to receive a bug report with the requested information.

- Fletch

-Original Message-
From: hlds-boun...@list.valvesoftware.com 
[mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Fletcher Dunn
Sent: Thursday, December 08, 2011 1:50 PM
To: Half-Life dedicated Linux server mailing list; Half-Life dedicated Win32 
server mailing list (h...@list.valvesoftware.com)
Subject: Re: [hlds] [hlds_linux] STEAMAUTH: Client PLAYERNAME received failure 
code 6

We've had a hard time fixing this for several reasons.  First, we've never been 
able to reproduce this.  Second, the issue is confounded by the fact that 
client crashes can often produce this.  The last round of reports we got for 
this problem seemed to always be muddled by client crashes --- which can 
definitely happen in large batches, BTW, depending on the bug.  We never got a 
good set of reports that weren't muddled by client crashes.  For Orangebox, we 
recently (within the last month) made a change that would try to distinguish 
between a true client auth problem, and a client crash, so hopefully that 
confounding factor can be separated.  (And we hope that the past week or so has 
seen a good increase in stability.)

We believe you that this bug still exists, and we do want to fix it.

If I could beg the patience of the server operators, and once more solicit 
detailed reports of this problem.  We will once again try to examine those 
reports and fix it.  I'll try to do a better job staying on top of this issue 
and keeping people informed about what we're doing, so we can close this bug.

Here's what is needed in order for us to investigate this:
* The time of the event.  Please remember to provide your local time zone, so 
we can correlate any timestamps in your logs to timestamps in our logs.
* Logs:
- The complete server log.  Please don't trim the log, just send the 
whole thing.  The login info can be useful, and perhaps other events that 
occurred previously.
- The complete console transcript.  If you are experiencing this 
problem and are not configured to capture the console output, please do so.
- Make sure we can easily locate the portion of the logs corresponding 
to the event.  (Timestamps should be sufficient, but they typically are not 
present for the console transcript.)
* We'd greatly prefer to get the complete logs.  But if this is not possible, 
and you are certain you have a good example, the bare minimum we'll need is:
- Public IP address of your server.  (For TF2 servers, this is output 
at near the time when you server logs onto Steam, in case you don't know it.)
- Steam ID's of the players who dropped.
* If you have multiple examples, please just pick one and send it.  If you have 
one really clear case where you are pretty sure the clients didn't crash, it 
will hopefully be enough to help us fix this problem.

We do care about this problem and want to fix it.  I'm sorry the issue has 
lingered.

Feel free to send these directly to my email address.  (Please zip up the big 
logs.)

One last thing: on December 6th, 2011, from about 3PM - 10PM US Pacific time, 
there was a known problem in our backend that might have manifested in issues 
like this.  It has been fixed.  Please don't send any examples near this time 
interval.

- Fletch

-Original Message-
From: hlds_linux-boun...@list.valvesoftware.com 
[mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of E3pO
Sent: Thursday, December 08, 2011 7:08 AM
To: Half-Life dedicated Linux server mailing list
Subject: [hlds_linux] STEAMAUTH: Client PLAYERNAME received failure code 6

STEAMAUTH: Client mipermip123 received failure code 6
STEAMAUTH: Client mipermip123 received failure code 6 L 12/08/2011 - 09:50:01: 
"PLAYERNAME <471>"
disconnected (reason "No Steam logon")
Dropped PLAYERNAME  from server (No Steam logon)

I've been getting these randomly the past few weeks on servers.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Players get disconnected with "STEAMAUTH: Client received failure code 6" error

[doc]

This is a problem but there have been a few reports to the mailing list
already about it. Also if you have a lot of text just give us a snippet and
throw the rest on www.pastebin.com , especially if it's the same line
multiple times and you're posting just for effect.

As far as I know there isn't anything you can "do" about this, it's steam
working issues out with itself OR it's a client crash and the steam servers
notice it before the client times out. If it's the later case then Valve is
working on making that process a bit more visible so they can start
diagnosing the issue. From what I understand it's a hard bug to reproduce
on a whim.

On Mon, Dec 12, 2011 at 12:10 PM, Laurenz Ruprecht
wrote:

> Hello friends,
>
>
>
> since many days the servers (there are 23 servers of us) get error
> messages like that:
>
>
>
> ###
>
>
>
> STEAMAUTH: Client Anubis PT received failure code 6
>
> STEAMAUTH: Client Anubis PT received failure code 6
>
> Dropped Anubis PT from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Piet Pistol received failure code 6
>
> STEAMAUTH: Client Piet Pistol received failure code 6
>
> Dropped Piet Pistol from server (No Steam logon
>
> )
>
> STEAMAUTH: Client BiDeauChOn.59 received failure code 6
>
> STEAMAUTH: Client BiDeauChOn.59 received failure code 6
>
> Dropped BiDeauChOn.59 from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Yakhoden received failure code 6
>
> STEAMAUTH: Client Yakhoden received failure code 6
>
> Dropped Yakhoden from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Chr!s.K received failure code 6
>
> STEAMAUTH: Client Chr!s.K received failure code 6
>
> Dropped Chr!s.K from server (No Steam logon
>
> )
>
> STEAMAUTH: Client MiniGates received failure code 6
>
> STEAMAUTH: Client MiniGates received failure code 6
>
> Dropped MiniGates from server (No Steam logon
>
> )
>
> STEAMAUTH: Client catto received failure code 6
>
> STEAMAUTH: Client catto received failure code 6
>
> Dropped catto from server (No Steam logon
>
> )
>
> STEAMAUTH: Client ॐ LOST ॐ received failure code 6
>
> STEAMAUTH: Client ॐ LOST ॐ received failure code 6
>
> Dropped ॐ LOST ॐ from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Laonder received failure code 6
>
> STEAMAUTH: Client Laonder received failure code 6
>
> Dropped Laonder from server (No Steam logon
>
> )
>
> STEAMAUTH: Client ZeCraZyCLoWn [Sine Metu] received failure code 6
>
> STEAMAUTH: Client ZeCraZyCLoWn [Sine Metu] received failure code 6
>
> Dropped ZeCraZyCLoWn [Sine Metu] from server (No Steam logon
>
> )
>
> STEAMAUTH: Client sh4rK received failure code 6
>
> STEAMAUTH: Client sh4rK received failure code 6
>
> Dropped sh4rK from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Rebell received failure code 6
>
> STEAMAUTH: Client Rebell received failure code 6
>
> Dropped Rebell from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Ronox received failure code 6
>
> STEAMAUTH: Client Ronox received failure code 6
>
> Dropped Ronox from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Pumoggel received failure code 6
>
> STEAMAUTH: Client Pumoggel received failure code 6
>
> Dropped Pumoggel from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Anja83 received failure code 6
>
> STEAMAUTH: Client Anja83 received failure code 6
>
> Dropped Anja83 from server (No Steam logon
>
> )
>
> STEAMAUTH: Client Titan received failure code 6
>
> STEAMAUTH: Client Titan received failure code 6
>
> Dropped Titan from server (No Steam logon
>
> )
>
> STEAMAUTH: Client dirtychamber received failure code 6
>
> STEAMAUTH: Client dirtychamber received failure code 6
>
> Dropped dirtychamber from server (No Steam logon
>
> )
>
> STEAMAUTH: Client glow@ Birthday received failure code 6
>
> STEAMAUTH: Client glow@ Birthday received failure code 6
>
> Dropped glow@ Birthday from server (No Steam logon
>
> )
>
> STEAMAUTH: Client T@rri received failure code 6
>
> STEAMAUTH: Client T@rri received failure code 6
>
> Game will not start until both teams have players.
>
> Dropped T@rri from server (No Steam logon
>
> )
>
>
>
> ###
>
>
>
> What is that?
>
>
>
> This is really terrible because there are playing 400 - 500 players on our
> servers at the evenining and then many players (100 players) are
> disconnected.
>
>
>
> Best regards,
>
>
>
> Lawrence
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Server locking up with 100% cpu usage

[Mart-Jan Reeuwijk]

+1



>
> From: Jesse Molina 
>To: Half-Life dedicated Linux server mailing list 
> 
>Sent: Monday, 12 December 2011, 9:00
>Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> 
>
>Stop doing that.
>
>
>
>Michael Johansen wrote:
>> and it is running under realtime-priority.
>
>-- # Jesse Molina
># Mail = je...@opendreams.net
># Page = page-je...@opendreams.net
># Cell = 1.602.323.7608
># Web  = http://www.opendreams.net/jesse/
>
>
>
>___
>To unsubscribe, edit your list preferences, or view the list archives, please 
>visit:
>https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Server locking up with 100% cpu usage

[Michael Johansen]

Yes.

> Date: Mon, 12 Dec 2011 13:31:15 +0100
> From: daniel.joki...@gmail.com
> To: hlds_linux@list.valvesoftware.com
> Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> 
> This is the script you use?
> 
> http://www.ulrich-block.de/tutorials/counter-strike-source-und-tf-2-linux-server-how-to/
> On 12 Dec 2011 10:32, "Michael Johansen"  wrote:
> >
> >
> > I've been trying to replicate the problem but I'm unable to do it, lols.
> I have removed the output to /dev/null and I took it off the realtime
> scheduling. Very, very weird. Would the actual cron, or screen application
> be able to cause this?
> > - Michael
> >
> > > From: michs...@live.no
> > > To: hlds_linux@list.valvesoftware.com
> > > Date: Mon, 12 Dec 2011 08:57:36 +0100
> > > Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> > >
> > >
> > > Some more info: The process is ran by its own user, and it is running
> under realtime-priority.
> > >
> > > > Date: Sun, 11 Dec 2011 15:33:56 -0700
> > > > From: je...@opendreams.net
> > > > To: hlds_linux@list.valvesoftware.com
> > > > Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> > > >
> > > >
> > > > Sending a "stop" or "quit" (or whatever works, I use quit) to the
> > > > console is good.  A lot of people miss that and just send kill -9 to
> the
> > > > binary process (srcds_linux) and don't realize that the bash script
> > > > (srcds_run) will auto-restart the process via crash recovery.
> > > >
> > > > However, it looks like the immediate next thing done in the script is
> to
> > > > kill the whole screen process, which would kill everything in it.
>  There
> > > > is no wait between sending the quit command, so the server is not
> > > > cleanly quitting and clients are probably not being cleanly notified.
> > > > You need to give the server a little time to actually quit.  At the
> very
> > > > least, put a "sleep 3" in there right after the "echo -n "Stoppe
> > > > $SCREENNAME" or something.
> > > >
> > > > In my script, I send a quit, monitor the process for something like
> ten
> > > > seconds to verify that it actually quit, and then kill the whole tmux
> > > > (like screen) session.  It's not a quick process because srcds servers
> > > > like to crash when "quit" is issued, which is awesome.
> > > >
> > > > Anyway, this looks pretty reasonable.
> > > >
> > > >
> > > >
> > > > Mike Johansen wrote:
> > > > > By killing it I mean:
> > > > >
> > > > > function stop_server {
> > > > >   if [[ `screen -ls | grep $SCREENNAME` ]]; then
> > > > >   echo -n "Stoppe $SCREENNAME"
> > > > >   kill `screen -ls | grep $SCREENNAME | awk -F . '{print $1}'| awk
> '{print
> > > > > $1}'`
> > > > >   echo " ... done."
> > > > >   else
> > > > >   echo "Konnte den Screentab $SCREENNAME nicht finden"
> > > > >   fi
> > > > > }
> > > > >
> > > > > This is not my script, I got it from another site. And the host
> does not go
> > > > > down, I never said that, it locks up. It's online, and the hardware
> has been
> > > > > tested yesterday by the DC and they can report that the hardware is
> as
> > > > > stable as can be. The only thing the logs show is the usual stuff,
> it does
> > > > > not report anything useful in terms of the srcds locking up.
> > > >
> > > > --
> > > > # Jesse Molina
> > > > # Mail = je...@opendreams.net
> > > > # Page = page-je...@opendreams.net
> > > > # Cell = 1.602.323.7608
> > > > # Web  = http://www.opendreams.net/jesse/
> > > >
> > > >
> > > >
> > > > ___
> > > > To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> > > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
  
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Checking for third party DS updates?

[Chris Strand]

I would also love to see such an API. My system for managing updates at the
moment just seems like a big 'hack' to me. Being able to query version
numbers would allow for a much more elegant solution.

Chris

On 11 December 2011 21:29, Michael Tharp  wrote:

> On 12/10/2011 02:56 AM, Tony Paloma wrote:
>
>> It sounds like you're looking for a web API to get the current versions
>> of a given app's depots, but unfortunately no such API exists.
>>
>
> I would like to humbly request such an API, it would make polling for
> optional updates much easier for me and less traumatic on Steam resources.
> The UpToDateCheck call is already a big step forward, just this little bit
> more will help a great deal.
>
> Thanks,
> -- m. tharp
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Server locking up with 100% cpu usage

[daniel jokiaho]

This is the script you use?

http://www.ulrich-block.de/tutorials/counter-strike-source-und-tf-2-linux-server-how-to/
On 12 Dec 2011 10:32, "Michael Johansen"  wrote:
>
>
> I've been trying to replicate the problem but I'm unable to do it, lols.
I have removed the output to /dev/null and I took it off the realtime
scheduling. Very, very weird. Would the actual cron, or screen application
be able to cause this?
> - Michael
>
> > From: michs...@live.no
> > To: hlds_linux@list.valvesoftware.com
> > Date: Mon, 12 Dec 2011 08:57:36 +0100
> > Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> >
> >
> > Some more info: The process is ran by its own user, and it is running
under realtime-priority.
> >
> > > Date: Sun, 11 Dec 2011 15:33:56 -0700
> > > From: je...@opendreams.net
> > > To: hlds_linux@list.valvesoftware.com
> > > Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> > >
> > >
> > > Sending a "stop" or "quit" (or whatever works, I use quit) to the
> > > console is good.  A lot of people miss that and just send kill -9 to
the
> > > binary process (srcds_linux) and don't realize that the bash script
> > > (srcds_run) will auto-restart the process via crash recovery.
> > >
> > > However, it looks like the immediate next thing done in the script is
to
> > > kill the whole screen process, which would kill everything in it.
 There
> > > is no wait between sending the quit command, so the server is not
> > > cleanly quitting and clients are probably not being cleanly notified.
> > > You need to give the server a little time to actually quit.  At the
very
> > > least, put a "sleep 3" in there right after the "echo -n "Stoppe
> > > $SCREENNAME" or something.
> > >
> > > In my script, I send a quit, monitor the process for something like
ten
> > > seconds to verify that it actually quit, and then kill the whole tmux
> > > (like screen) session.  It's not a quick process because srcds servers
> > > like to crash when "quit" is issued, which is awesome.
> > >
> > > Anyway, this looks pretty reasonable.
> > >
> > >
> > >
> > > Mike Johansen wrote:
> > > > By killing it I mean:
> > > >
> > > > function stop_server {
> > > >   if [[ `screen -ls | grep $SCREENNAME` ]]; then
> > > >   echo -n "Stoppe $SCREENNAME"
> > > >   kill `screen -ls | grep $SCREENNAME | awk -F . '{print $1}'| awk
'{print
> > > > $1}'`
> > > >   echo " ... done."
> > > >   else
> > > >   echo "Konnte den Screentab $SCREENNAME nicht finden"
> > > >   fi
> > > > }
> > > >
> > > > This is not my script, I got it from another site. And the host
does not go
> > > > down, I never said that, it locks up. It's online, and the hardware
has been
> > > > tested yesterday by the DC and they can report that the hardware is
as
> > > > stable as can be. The only thing the logs show is the usual stuff,
it does
> > > > not report anything useful in terms of the srcds locking up.
> > >
> > > --
> > > # Jesse Molina
> > > # Mail = je...@opendreams.net
> > > # Page = page-je...@opendreams.net
> > > # Cell = 1.602.323.7608
> > > # Web  = http://www.opendreams.net/jesse/
> > >
> > >
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list
archives, please visit:
> > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Server locking up with 100% cpu usage

[Michael Johansen]

I've been trying to replicate the problem but I'm unable to do it, lols. I have 
removed the output to /dev/null and I took it off the realtime scheduling. 
Very, very weird. Would the actual cron, or screen application be able to cause 
this? 
- Michael

> From: michs...@live.no
> To: hlds_linux@list.valvesoftware.com
> Date: Mon, 12 Dec 2011 08:57:36 +0100
> Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> 
> 
> Some more info: The process is ran by its own user, and it is running under 
> realtime-priority. 
> 
> > Date: Sun, 11 Dec 2011 15:33:56 -0700
> > From: je...@opendreams.net
> > To: hlds_linux@list.valvesoftware.com
> > Subject: Re: [hlds_linux] Server locking up with 100% cpu usage
> > 
> > 
> > Sending a "stop" or "quit" (or whatever works, I use quit) to the 
> > console is good.  A lot of people miss that and just send kill -9 to the 
> > binary process (srcds_linux) and don't realize that the bash script 
> > (srcds_run) will auto-restart the process via crash recovery.
> > 
> > However, it looks like the immediate next thing done in the script is to 
> > kill the whole screen process, which would kill everything in it.  There 
> > is no wait between sending the quit command, so the server is not 
> > cleanly quitting and clients are probably not being cleanly notified. 
> > You need to give the server a little time to actually quit.  At the very 
> > least, put a "sleep 3" in there right after the "echo -n "Stoppe 
> > $SCREENNAME" or something.
> > 
> > In my script, I send a quit, monitor the process for something like ten 
> > seconds to verify that it actually quit, and then kill the whole tmux 
> > (like screen) session.  It's not a quick process because srcds servers 
> > like to crash when "quit" is issued, which is awesome.
> > 
> > Anyway, this looks pretty reasonable.
> > 
> > 
> > 
> > Mike Johansen wrote:
> > > By killing it I mean:
> > >
> > > function stop_server {
> > >   if [[ `screen -ls | grep $SCREENNAME` ]]; then
> > >   echo -n "Stoppe $SCREENNAME"
> > >   kill `screen -ls | grep $SCREENNAME | awk -F . '{print $1}'| awk '{print
> > > $1}'`
> > >   echo " ... done."
> > >   else
> > >   echo "Konnte den Screentab $SCREENNAME nicht finden"
> > >   fi
> > > }
> > >
> > > This is not my script, I got it from another site. And the host does not 
> > > go
> > > down, I never said that, it locks up. It's online, and the hardware has 
> > > been
> > > tested yesterday by the DC and they can report that the hardware is as
> > > stable as can be. The only thing the logs show is the usual stuff, it does
> > > not report anything useful in terms of the srcds locking up.
> > 
> > -- 
> > # Jesse Molina
> > # Mail = je...@opendreams.net
> > # Page = page-je...@opendreams.net
> > # Cell = 1.602.323.7608
> > # Web  = http://www.opendreams.net/jesse/
> > 
> > 
> > 
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives, 
> > please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> 
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
  
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] Server locking up with 100% cpu usage

[Jesse Molina]

Stop doing that.



Michael Johansen wrote:

and it is running under realtime-priority.


--
# Jesse Molina
# Mail = je...@opendreams.net
# Page = page-je...@opendreams.net
# Cell = 1.602.323.7608
# Web  = http://www.opendreams.net/jesse/



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux