Re: [hlds_linux] Mandatory Team Fortress 2 Update Released

[PharaohsPaw]

>> Unless there's some really weird issue with certain update servers

this ^^^ is a pretty good candidate if you ask me



Anyway, there are people who "have never had a problem".  At least one of
them who uses nemrun, but only as a way to tell the many, many actual
servers they run to initiate their own updates.  I don't know how it makes
a difference, but apparently somehow it does.  I've thought this through
and made a few changes to the nemrun 1.8.5 scripts to add some time delay
knobs etc. (as posted here a while back).  Obviously waiting a few seconds
to give the master/depot/content/shmontent servers time to replicate the
updates isn't the problem.

I don't have any control over the return codes the steam binary exits with
and I sure don't have any control over what steam's masters and
distribution servers have on them, what they feed me when there is an
update available, whether they rudely "hang up" with a connection reset or
lie to me when they say I am now up to date, etc.

Looks like about all I can really do if I want a true "fuhgeddaboudit"
auto-updating solution that only has to update ONE HLDS (TF2) directory
tree to update all the servers, and that I don't have to fawn over or
manually intervene in the majority of the times an update comes out is to
use -verify_all all the time.

And "fuhgeddaboudit" also with regard to how long it takes for the update
to finish and get the servers back online.

...because it is not possible to have a content server reliably feed you
JUST THE FILES THAT CHANGED BETWEEN THE VERSION YOU REPORTED IN WITH AND
THE VERSION THE MASTER IS AT NOW.

What really wizzes me off though is how often the problem is assumed to be
on MY end just because I am having problems.




___
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] Mandatory Team Fortress 2 Update Released

[PharaohsPaw]

> I've love to know what you're doing wrong then, because everything's fine
> here.
>
> Unless there's some really weird issue with certain update servers and it
> just so happens all the ones at my side of the world are fine...
>

It's not what *I'm* doing wrong.  The script (nemrun) I run responds only
to what it is TOLD.  By STEAM.

Nemrun checks steam API periodically to see if it tells us we are out of
date.

If steam tells us we are out of date, nemrun initiates an update.

note that "nemrun initiates an update" means, "./steam -command update
-game tf -dir /home/tf2/tf2 -retry".

I happened to be near keyboard/console for this update so I watched it.

In a nutshell, it "updated" the server directory tree without actually
updating much of anything.  The first time around.  It didn't update
steam.inf.  But we got an HLDS Installation is Up to Date, and the steam
binary exited with a 0 return code.

THE STEAM BINARY THAT ACTUALLY DOES THE UPDATING EXITED WITH A 0 RETURN CODE.

After that, nemrun basically got stuck in a verify/re-update loop of
"update completed but the steam master tells us we are still out of date".
 Until I killed all the servers and the updater daemon and fired up the
-verify_all version of the updater daemon script I have to use when stuff
like this happens.

Approximately 45 minutes later, it finally finished.

Interestingly enough, only then did I get the majority of the files
actually *IN* the update.  (so, why the heck did I get a 'successful
update' from whichever master/disaster/depot server I was "updating" from,
then?)

Oh and wait, there's more.  The post I made the other day, talking about
getting a 104 Connection Reset by Peer after you are 100% updated?  It
happened with this first -verify_all pass.  So even though I now had 100%
of the files, guess what... had to go through -verify_all again.

It's not what I'm doing wrong.  If you can't trust what the steam binary
tells you and return codes


>> -Original Message-
>> From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-
>> boun...@list.valvesoftware.com] On Behalf Of PharaohsPaw
>> Sent: 17 January 2012 20:46
>> To: Half-Life dedicated Linux server mailing list
>> Subject: Re: [hlds_linux] Mandatory Team Fortress 2 Update Released
>>
>> > We've released a mandatory update to Team Fortress 2. The notes for
>> the
>> > update are below.
>> >
>> > -Eric
>>
>> while [ true ] ; do
>>
>> echo "steam.inf missing"
>>
>> done
>>
>>
>> ___
>> 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] Mandatory Team Fortress 2 Update Released

[PharaohsPaw]

> We've released a mandatory update to Team Fortress 2. The notes for the
> update are below.
>
> -Eric

while [ true ] ; do

echo "steam.inf missing"

done


___
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] another request about update releases

[PharaohsPaw]

>
> Dont some scripts just check the steam.inf (or what that file was) for the
> version number?
>
> But indeed, that should be better.

Well, nemrun does check the steam.inf file to build a query to the master
to see if a newer version is available, and it does try to "verify the
update" after one is finished -- but it doesn't try to "verify" the update
(make sure a steam.inf exists, etc.) until the steam binary that actually
updates the server files exits with a 0 return code.

The problem I'm mentioning here is that for whatever reason after the
update has hit 100% (which I am pretty sure means, we have successfully
pulled in all of the files comprising this update), the master end
abruptly terminates the connection/session a lot of the time, (connection
reset by peer usually means exactly that, they RST our TCP connection on
us) rather than issuing some form of an "OK that's all the files, we're
done here" app-layer response to the dedicated server (steam binary
updating it) - which causes the steam binary to think it didn't finish
successfully, and repeat.

Of course, since we have all the updated files now, it won't pull any more
files in.  But we have to go through the whole process of another attempt
anyway to get a "success" (or whatever it is) app-layer response from the
steam content server so that we can get a successful exit code out of the
steam binary.

Again I really don't have any visibility of their side of things but I do
suspect that there might be something code-wise on the master end that
handles returning success responses differently (ie, not politely) when it
actually HAS sent us files to get us up to date, vs. when it didn't need
to send us any files.  If that makes sense.

Because what it has ended up meaning, at least most of the updates I
watched get served out, is that even when we get 100% of the updated
files, it always fails the first time and has to go through the whole
shebang again.

Lately this has meant the servers are down for another 30 minutes or so -
for no good reason. :)  Just because the master hung up on us abruptly
rather than return whatever message the steam client needs to get from the
master to tell it "all done, HLDS Installation is Up to Date", the first
time around.





___
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] another request about update releases

[PharaohsPaw]

Hi,

Another thing I've been noticing about updating the servers anytime
recently is that most of the time, if not all of the time, a "104
connection reset by peer" occurs even when an update has (apparently)
fully completed.

If this did not occur, the steam client would exit with a normal return
code and the server could come back up.  Instead, probably many of the
various scripts we all run our servers under see this non-zero return code
and assume it needs to make another pass.  Which delays our servers coming
back up.

Here is example from this evening's update, demonstrating this:

(this is a nemrun-initiated update but nemrun or not doesn't matter):

---
[Wed Jan 11 20:45:46 EST 2012] :: Using command: ./steam -dir
"/home/tf2/tf2/" -game "tf" -command update -retry
Checking bootstrapper version ...
Updating Installation
Updating 'Team Fortress 2 Content' from version 307 to version 308

8.20%   downloading /home/tf2/tf2//orangebox/tf/bin/server.dll
19.32%  downloading /home/tf2/tf2//orangebox/tf/bin/server.dylib
38.06%  downloading /home/tf2/tf2//orangebox/tf/bin/server.so
49.03%  downloading /home/tf2/tf2//orangebox/tf/maps/graphs/cp_dustbowl.ain
49.03%  downloading /home/tf2/tf2//orangebox/tf/maps/graphs/cp_granary.ain
49.03%  downloading /home/tf2/tf2//orangebox/tf/maps/graphs/cp_gravelpit.ain
49.03%  downloading /home/tf2/tf2//orangebox/tf/maps/graphs/cp_well.ain
49.03%  downloading /home/tf2/tf2//orangebox/tf/maps/graphs/ctf_2fort.ain
49.46%  downloading /home/tf2/tf2//orangebox/tf/maps/cp_foundry_l_0.lmp
49.46%  downloading /home/tf2/tf2//orangebox/tf/resource/mapinfo.txt
51.21%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_brazilian.txt
52.88%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_danish.txt
54.75%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_dutch.txt
55.58%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_english.txt
57.38%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_finnish.txt
59.29%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_french.txt
61.19%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_german.txt
63.03%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_hungarian.txt
64.85%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_italian.txt
65.98%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_japanese.txt
67.21%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_korean.txt
68.44%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_koreana.txt
69.90%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_norwegian.txt
71.77%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_polish.txt
73.58%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_portuguese.txt
75.25%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_romanian.txt
77.08%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_russian.txt
78.59%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_schinese.txt
80.47%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_spanish.txt
82.29%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_swedish.txt
83.71%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_tchinese.txt
85.52%  downloading /home/tf2/tf2//orangebox/tf/resource/tf_turkish.txt
86.67%  downloading /home/tf2/tf2//orangebox/tf/scripts/items/items_game.txt
86.72%  downloading /home/tf2/tf2//orangebox/tf/sound/vo/spy_thanks01.wav
86.72%  downloading /home/tf2/tf2//orangebox/tf/steam.inf

Updating 'Team Fortress 2 Materials' from version 159 to version 160
86.72%  downloading
/home/tf2/tf2//orangebox/tf/materials/backpack/player/items/soldier/luckyshot.vmt
86.72%  downloading
/home/tf2/tf2//orangebox/tf/materials/backpack/player/items/soldier/luckyshot_large.vmt
86.72%  downloading
/home/tf2/tf2//orangebox/tf/materials/models/player/items/soldier/luckyshot_blue.vmt
86.72%  downloading
/home/tf2/tf2//orangebox/tf/materials/models/player/items/soldier/luckyshot_red.vmt
86.76%  downloading
/home/tf2/tf2//orangebox/tf/models/player/items/soldier/luckyshot.dx90.vtx
86.76%  downloading
/home/tf2/tf2//orangebox/tf/models/player/items/soldier/luckyshot.mdl
86.76%  downloading
/home/tf2/tf2//orangebox/tf/models/player/items/soldier/luckyshot.phy
86.83%  downloading
/home/tf2/tf2//orangebox/tf/models/player/items/soldier/luckyshot.vvd

Checking/Installing 'Base Source Shared Materials' version 8


Checking/Installing 'Base Source Shared Models' version 4

Checking/Installing 'Base Source Shared Sounds' version 4


Updating 'OB Linux Dedicated Server' from version 144 to version 145
87.45%  downloading /home/tf2/tf2//orangebox/bin/datacache.so
88.36%  downloading /home/tf2/tf2//orangebox/bin/dedicated.so
92.08%  downloading /home/tf2/tf2//orangebox/bin/engine.so
92.41%  downloading /home/tf2/tf2//orangebox/bin/libtier0.so
92.70%  downloading /home/tf2/tf2//orangebox/bin/libvstdlib.so
94.61%  downloading /home/tf2/tf2//orangebox/bin/materialsystem.so
95.74%  downloading /home/tf2/tf2//orangebox/bin/replay.so
95.86%  downloading /home/tf2/tf2//orangebox/

Re: [hlds_linux] Replay - quickplay scoring penality

[PharaohsPaw]

> OCCUPY
> VALVE
> THEY'VE GIVEN US THE TOOLS TO RUN SERVERS TOO LONG IT'S TIME WE STRIKE
> BACK
> AGAINST THE HAND THAT FEEDS

This is getting pretty ridiculous, dude.  You are upset over a non-issue.

You act as if quickplay sending you players is the only way to get your
server populated.  Trust me, quickplay is not going to compensate for an
empty server or magically fill it up for you.  It doesn't even claim to,
in fact, I'm pretty sure I read that the more players your server has on
it, the more it is going to send your way.

Why?

Repeat after me:

Nobody wants to play on an empty server.

Stand in front of a mirror and repeat that until you get it, if it helps.

Can you imagine how much whining would go on in the steam forums if
quickplay sent all the players that use it to "find" a server to play on
to empty servers?

Your servers are still in the server browser.  Deliberately blurring this
a bit, I think everyone can agree that "a significant amount" of the
experienced players who play the game are going to use the server browser,
not quickplay.  And guess where they are going to go, if they aren't going
to servers they have set in their favorites?  ie, if they are looking for
new/different servers to try out?

lowest ping.  busy server.

See?

Having a busy server is going to do a lot more to BRING you more traffic
than any scoring penalty that *MIGHT* be imposed because of having a 25
player count will COST you.  But from what everyone else is saying, it
doesn't sound like that even counts against you.  I didn't get that
impression reading Valve's quick play doco for server operators either. 
Check your server tags and see if increased max players is reported.  If
it isn't, then it should prove this is a completely empty argument.

Incidentally, I have my maxplayers at 25 and have replay and sourcetv
disabled - the extra slot is a sourcemod-managed reserve slot and I have
it configured to keep it open and hide it.  So visible max players stays
at 24, people with reserve access can still get in, and guess what. 
increasedmaxplayers does NOT show up in sv_tags once the server has fully
initialized.

(and Valve while I do appreciate and applaud your efforts to punish the
folks hacking/modding the server to deliberately misrepresent player
count, bots, tags, etc.  I do hope the many legitimate needs/reasons to
have a reserve slot will always be kept in mind and respected as these
efforts evolve and not count against us).

You need to remember that Valve DOES let us regular folks operate
dedicated servers, unlike certain other game software companies where
unless you are a GSP with some kind of special relationship, you can't
even GET the dedicated server software.  So maybe you need to think about
that the next time you cat /dev/urandom into an email to this list.

(And off-topic but just throwing this out there I don't plan to buy
any games I can't get free dedicated server software for.  Because doing
so supports companies who think regular folks are incapable of running
high quality servers or that the only people who would want to do so are
pirates and hackers.  Why should I support a company that basically
doesn't trust me?)


___
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 auth timeouts

[PharaohsPaw]

> I wanted to pass on the news that we believe we have identified the cause
> of the steam auth timeouts that cause groups of players to all get
> disconnected drop at once.  (No, we had not forgotten about it!)

Thanks Fletch and everyone there working on it.



___
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] please lock maxplayers

[PharaohsPaw]

> If you're a GSP, you alone should totally be monitoring your clients.
>
> Don't cripple a legitimate feature.
> Kyle.

Indeed, this is the other thing I was thinking about.  My previous post
did not even take into consideration the various plugin/mod/hook ways you
could forcibly modify the max player slots on a server.  As others have
said, if somebody really wants to change the value a way will be found to
do it.  Once upon a time TF2 was locked at 24 and mods like beetlemod were
the only way to  get past it.

But asking the software company to lock the dedicated server's maxplayers
setting to some value, or make maxplayers have more "teeth" so your
customers "can't" rip you off is asking them to do your job for you.  This
is just my opinion but if you as a GSP don't know enough about the games
you are charging money to serve then you probably shouldn't be charging
money for your service.


___
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] please lock maxplayers

[PharaohsPaw]

IIRC what you set on the commandline *IS* the highest you can set it, and
although I'm less certain about this, I don't think any attempt to set
maxplayers to a higher value than what was set on the server command line
will work.

Please do us a favor however and do not ask valve to lock things such as
maxplayers.  Things a lot of operators really don't want have a funny way
of showing up in updates. :)

Personally I don't really care about having big servers but there are some
operators who have the hardware and bandwidth to handle it properly, and
continue to operate them quite successfully and I would much rather Valve
leave it up to the server operator's discretion than lock it at some
quasi-arbitrary value.

Does setting "+maxplayers <# you want as upper limit>" among the command
line options not work for you?


> You can change the cvar maxplayers before the game starts.
> When you put this two lines in your autoexec.cfg the maxplayers cvar is
> overwritten and fixed (tested with css):
>
> maxplayers 64
> map de_dust
>
> Maybe Valve can lock maxplayers, when it is set with -maxplyers in the
> start command.
> ___
> 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] Mandatory TF2 update coming soon

[PharaohsPaw]

Thanks again for the heads up!

> We should have it ready in the next 30 minutes or so.
>
> -Eric
>
>
> ___
> 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] [PATCH POST] Some changes I made to nemrun 1.8.5 script

[PharaohsPaw]

> a link to pastebin.com works imo best, not having to deal with extensive
> length mails, or having problems with the formatting email clients apply,
> etc.

Allright, for any who prefers pastebin for the patch, here it is:

http://pastebin.com/rkWcBWZd


It's a "-p0" patch, and you'll have to type the name of the file you want
to patch (unless yours happens to be named the same thing as mine).



___
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] [EXAMPLE .CFG FILES] Some changes I made to nemrun 1.8.5 script

[PharaohsPaw]

>> Nope, the attachments were stripped.
>
> Yep, unfortunately.  Guess I'll have to try to post the patch inline.
> it's ~11KB...
>
> Will post it as a separate reply.
>

OK it looks like the inline post worked.  This is more or less the same
way patch posts get posted to kernel mailing lists etc.  If you're
interested in using this theres a good chance you could save the message
text as a file and then apply it (do a patch --verbose --dry-run to find
out).


WARNING
Now, I do need to mention that although I called the -sharedalertcommand
and -sharedkillalertcommand "optional" in the usage output, the truth is
it is not really optional (at this time) because I don't have logic in
there to handle what to do if a value isn't defined.  A default value is
set at the top of the script.  If you don't want to use this (why wouldnt
you?) you could define something else like

-sharedalertcommand "echo nemrun has found an update"
-sharedkillalertcommand "echo nemrun is killing the servers"

(which will make those show up in local server console but not in game),
so the stuffing an execute of the default .cfg files at least gets
overridden.

I'll change this at some point so it actually IS optional.  When I set out
on doing these changes it was "for me first" so I set how I'd want to use
it as default. :)

Also, need to say that I am not trying to steal nephyrin's thunder here. 
I just made a few changes for what I am trying to do with nemrun.  These
things may be stupid or completely useless to anybody else.  But in case
anybody else is interested, this is what I did.  All credit for nemrun
belongs to nephyrin, not me.

So, here's the example .cfg files:

example: pending-update-alert.cfg

// commands to run when nemrun update daemon
// has detected a server update is available
// (console say commands to alert current
// players etc.)
//
// example commands if we are updating first (not taking server down to
update):
//sm_hsay Steam server update available!  Updating server NOW.
//sm_csay Steam server update available!  Updating server NOW.
//sm_say SERVER update available - Updating NOW. SERVER WILL RESTART (and
fill up fast!!) WHEN UPDATE IS COMPLETE
//sm_say SERVER update available - Updating NOW. SERVER WILL RESTART (and
fill up fast!!) WHEN UPDATE IS COMPLETE
//sm_say SERVER update available - Updating NOW. SERVER WILL RESTART (and
fill up fast!!) WHEN UPDATE IS COMPLETE
//
// example commands if we are taking servers down to update:
sm_hsay Required server update released! Rebooting in 2 minutes!
sm_csay Required server update released! Rebooting in 2 minutes!
sm_say A Required SERVER update has been released. We will be rebooting to
update in 2 minutes!
sm_say A Required SERVER update has been released. We will be rebooting to
update in 2 minutes!
sm_say A Required SERVER update has been released. We will be rebooting to
update in 2 minutes!
---

example update-reboot-alert.cfg:
---
// alert players the server is about to reboot
sm_hsay Server going DOWN to UPDATE in 10 SECONDS!!!
sm_csay Server going DOWN to UPDATE in 10 SECONDS!!!
sm_say Server is going DOWN to update in 10 SECONDS - Please check for a
game client update and reconnect for some action!
sm_say Server is going DOWN to update in 10 SECONDS - Please check for a
game client update and reconnect for some action!
sm_say Server is going DOWN to update in 10 SECONDS - Please check for a
game client update and reconnect for some action!
---

cheers

___
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] [PATCH POST] Some changes I made to nemrun 1.8.5 script

[PharaohsPaw]

Here is the patch inline, hope it comes across OK.


--- nemrun-1.8.52011-12-11 15:38:07.659276774 -0500
+++ nemrun-1.8.5-mine   2011-12-19 07:29:19.280445865 -0500
@@ -38,6 +38,13 @@ STARTTIME=`date`
 # These are defaults set later by command line options, see --help
# Command to send shared screens
SHAREDKILLCOMMAND="quit"
+   #SHAREDKILLCOMMAND="exec srvupdate.cfg"
+   # Command to send shared screens to alert currently
+   # connected players a mandatory update has been released
+   SHAREDALERTCOMMAND="exec pending-update-alert.cfg"
+   # Command to send shared screens to warn currently
+   # connected players we are about to restart the server
+   SHAREDKILLALERTCOMMAND="exec update-reboot-alert.cfg"
# Script to run when an update is found
NOTIFYCMD=""
# Script to run after updates complete
@@ -75,8 +82,15 @@ STARTTIME=`date`
SHAREDKILLWAIT="10"
# if set, we create core files according to pattern
COREFILE=""
-   # if set, verify_all for steam
+   # if set, use -verify_all and -retry for steam
VERIFYALL=""
+   # upon discovery of an available update, how long should we
+   # wait to give steam masters time to be READY to serve us the
+   # complete update before we try to pull it in? Default 10 (seconds)
+   UPDATEDELAY="10"
+   # How often (in seconds) should srcupdatecheck check in and see if a
+   # required update is available?  Minimum 2, default 20
+   CHECKINTERVAL="20"
 ##
 ## Functions
 ##
@@ -89,7 +103,9 @@ NemRun v1.8 - nephy...@doublezen.net, 07
 Usage: ./nemrun [-nemlog file [-nemlogtimestamp format]] [-cleandownloads age]
   [-autoupdate -steamdir dir -srvdir dir [(-sharedscreens screen[,screen[,...]]
   [-verify_all] [-sharedkillcommand command]) | (-shutdownscript 
script/command)
-  [-sharedkillwait seconds]] [-updatedaemon [-updatefirst]]] [-corefile file]
+  [-sharedkillwait seconds] [-sharedalertcommand servercommand]
+  [-sharedkillalertcommand servercommand] [-updatedaemon [-updatefirst]
+  [-updatedelay secs] [-checkinterval secs] [-corefile file]
   [server options]
 
-nemlog is the file update/reboot logs are saved to in addition to
@@ -110,7 +126,23 @@ Usage: ./nemrun [-nemlog file [-nemlogti
   finds one. Make sure you specify sharedscreens and add this screen to
   the shared screens list of all other servers so it doesn't interrupt
   their update.
-   !!This implies -autoupdate!!, see below.
+
+  !!This implies -autoupdate!!, see below.
+
+   -updatedelay - how long we should wait (in seconds) upon 
discovery
+  that a required update has been released should we wait 
before
+  we actually start to update.  This is to give the steam 
depots
+  serving the content time to make sure they actually HAVE all 
of
+  the updated files before we ask for them (since the steam 
binary
+  CAN return a 0 exit status and report 'HLDS Installation Is 
Up
+  to Date' when you didn't actually get all the files that were
+  supposed to be updated.  Default is 10 seconds.
+
+   -checkinterval - how often (in seconds) should we check in with
+  steam to see if there is a mandatory update.  Default is 
every
+  20 seconds.  Minimum allowable value is 2 but checking so
+  frequently isn't very nice and could cause you problems.
+
-updatefirst - if provided, update the servers *then* reboot
   them. Reduces downtime but could cause issues. Obviously only
   valid for update daemons. Experimental, might crash your
@@ -118,10 +150,14 @@ Usage: ./nemrun [-nemlog file [-nemlogti
   is using gets updated, or some such. Tested and works fine
   with binary-only updates (the steam tool deletes the .so
   before updating it, so no clobbering).
+
-verify_all
-  pass -verify_all ./steam when performing an update. Will make
+  pass -verify_all to ./steam when performing an update. Will 
make
   the update take slightly longer, but will ensure all files
-  are up to date.
+  are up to date.  This will also pass -retry along with it, 
since
+  it is rare these days that a -verify_all succeeds on the 
first
+  attempt before the connection is terminated with a 
Connection Reset
+  by Peer from the update server you are talking to.
 
-autoupdate - auto-updates the server on reboot.
-notifycmd command
@@ -153,6 +189,30 @@ Usage: ./nemrun [-nemlog file [-nemlogti
   OPTIONAL
   the command to send to the server consoles of the
 

Re: [hlds_linux] Some changes I made to nemrun 1.8.5 script (patch and example .cfg files attached)

[PharaohsPaw]

> Nope, the attachments were stripped.

Yep, unfortunately.  Guess I'll have to try to post the patch inline. 
it's ~11KB...

Will post it as a separate reply.






___
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] Some changes I made to nemrun 1.8.5 script (patch and example .cfg files attached)

[PharaohsPaw]

Hi everyone,

The discussion in the last week or so has led me to implement a few
changes to the nemrun script that I've been thinking about for a little
while anyway.  Some of these (sending alerts to connected players) I have
been doing for a while anyway but I don't think I ever shared any of it
with the rest of the community (here).

In case it is useful to anyone else or possibly could be considered (any
of it) for inclusion in a later nemrun, I'll attach a patch, the example
.cfg files containing the alert commands I use to warn connected players
an update has been released, and I'll also include an example command line
of me using this modified nemrun as the update daemon instance.

If the attachments don't attach properly (ie if they get blocked out) let
me know and we can figure out some other way to get them here.  The patch
is medium-to-large size so it may not be so great to post it "inline".

This may not be as useful for everybody using nemrun.  But keep in mind it
is configurable, what the different options do, and you can change your
.cfg files (what you say to your players, or any other cmds you might want
to throw in the .cfg files) to reflect how you use it.

The .cfg files go in the (game)/cfg/ directory. :)

Cheers

example command line for update daemon:

./nemrun \
 -nemlog "nemrunlogs/updater_%Y%m%d%H%M%S.log" \
 -cleandownloads 10 \
 -sharedkillwait 10 \
 -updatedelay 120 \
 -checkinterval 30 \
 -notifycmd $HOME/update-email \
 -autoupdate \
 -steamdir /home/tf2/tf2/ \
 -srvdir /home/tf2/tf2/ \
 -sharedscreens tf2-1,tf2-2,tf2-3,tf2-4 \
 -sharedalertcommand "exec pending-update-alert.cfg" \
 -sharedkillalertcommand "exec update-reboot-alert.cfg" \
 -game tf \
 -updatedaemon

description:
this is the update daemon instance.  The TF2 game install tree is
installed in user tf2's home directory, the top dir is /home/tf2/tf2. 
Orangebox dir is /home/tf2/tf2/orangebox, and steam.inf lives in
/home/tf2/tf2/orangebox/tf.  This setup takes the servers down BEFORE
updating.

There are 4 TF2 game instances, the screen names are tf2-1 through tf2-4.

This setup tells nemrun to check for updates every 30 seconds.  When a
mandatory update is found, it will stuff "exec pending-update-alert.cfg"
into each running game's console, executing a bunch of different say
commands to tell players an update has been released and when we will be
taking the servers down to get it.

When the server is actually going to go down (after the -updatedelay of
120 seconds) it then sends the shared kill alert command to tell players
the server is going down and to reconnect.  It is using sharedkillwait as
the amount of time to wait before killing the servers.

If they come through OK, here are the attachments.___
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] (ATTN: Valve) steam.inf missing and other "incomplete update" problems

[PharaohsPaw]

> It is "nicer" on the content delivery system if we only do one download
> per cluster for the hundreds of machines we run. It is also easier to deal
> with failures when they occur, since they only occur on the root server
> (what Fletcher called the master) of each cluster. We also do a bunch of
> config management and templating from these root servers. The system
> scales better this way and is more robust than each server doing their own
> updates. Also, there are complications with running multiple games from a
> single directory and using -autoupdate. This currently isn't possible to
> do without breaking your servers. The -autoupdate isn't designed for
> people running games this way. Maybe it ought to?

all of the above are why running nemrun (if you are using it this way, it
can be used in different ways) is a lot better for everybody.  speaking of
folks who do run multiple games from one server install tree.  You only
have to pester the steam content servers to update the game ONCE.  The
update daemon nemrun instance writes a lock file into the tree and sends a
quit to each running server, which, since they are also running the nemrun
script instead of srcds_run, check for existence of that lock file.  Since
it is there, they stay down until the lock is removed (while the update
daemon nemrun instance updates the tree).  Once nemrun has "verified the
update" (particuarly, verifying a steam.inf file exists), it removes the
lock and the servers come back up.

It has another mode where it updates the tree first (without taking the
games down) but I've never been adventurous enough to try it.  Seems to be
asking for weird probs for those connected players, at least depending on
what the update contains.

Speaking of nemrun, I have just finished making a bunch of changes to the
script (v1.8.5) which hopefully at least some of which some other people
might consider useful and maybe even some could be included in a future
version.  Will post to the list as a separate topic with a couple example
.cfg files for alerting connected players.



___
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] Mandatory TF2 update coming soon

[PharaohsPaw]

i just got it.  I got a steam.inf this time too :)

Thanks for the heads up!

> Includes what?Can i go sleep?
> On 16 Dec 2011 23:28, "Eric Smith"  wrote:
>
>> We should have it ready in the next 30 minutes or so.
>>
>> -Eric
>>
>>
>> ___
>> 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] (ATTN: Valve) steam.inf missing and other "incomplete update" problems

[PharaohsPaw]

Fletch, Steve, John, and everyone else:

Thank you for the information.  You've given me a lot to think about.


> I'm not an expert on the new content system, but I know that alternatives
> like this were considered.  Widespread ISP proxy support and the ability
> to temporarily expand bandwidth when Skyrim launches, etc are important
> factors that make rsync (or pretty much any custom protocol) undesirable.
> The new content system is based on HTTP fetching of "chunks."  It also
> dynamically grabs from different servers to automatically load balance.
> And no matter what the delivery protocol, the tool itself has some issues,
> as you've mentioned.  The new delivery system has a new update tool.
> We're hoping to migrate TF2 over to the new content system sometime next
> year.
>
> -Original Message-
> From: John Schoenick [mailto:nephy...@doublezen.net]
> Sent: Friday, December 16, 2011 1:49 PM
> To: Half-Life dedicated Linux server mailing list
> Cc: Fletcher Dunn
> Subject: Re: [hlds_linux] (ATTN: Valve) steam.inf missing and other
> "incomplete update" problems
>
> Are there any chances that we could get a rsync daemon on the new CDN
> servers to sync public repos? It's proven to be terribly reliable,
> supports renaming and file moves, and has modes to checksum all files,
> manage permissions, and so on. In fact, I would go as far as saying all
> that hldsupdatetool does, even if greatly improved with the new CDN, is
> act as a less featureful rsync.
>
> Additionally it would add all sorts of flexibility to update scripts.
> Telling when an update is optional vs required, moving files into place
> after they're all downloaded, detecting if this update is safe to run
> without shutting the server down first or locking it to one map, and so
> on. It would make our lives much, much easier.
>
> As for improving hldsupdatetool in the meantime, the issues I've noticed
> (nemrun works around some of these):
> - As noted, without -verify_all, it will miss files fairly regularly
> (protip: if you add -verify_all to nemrun's params it will always invoke
> the updatetool as such)
> - The tool will often give 'command aborted' or 'connection reset'.
> Sometimes mid-update, though *often* immediately after reaching 100%,
> making scripts that depend on the return value unable to tell if the
> update completed
> - Sometimes steam.inf just vanishes. The update tool deletes files before
> downloading new ones, so maybe this is a varient of the non-verify-all
> problems
> - Sometimes the tool seems to fail to detect timeouts, and will sit on
> 'updating files' indefinitely (hours) until you kill it.
> - The tool seems to not pick the best content server except on first
> startup, meaning on subsequent updates it will connect to severely
> overloaded servers. Deleting the clientregistry.blob prior to each update
> gives much better server selection.
>
> Also, if there's anything you would like nemrun and similar tools to do or
> not do to make your lives easier, do let us know!
>
> - John
>
> On 12/16/2011 11:45 AM, Fletcher Dunn wrote:
>> Sorry, I shouldn't have joined in with the shooting-from-the-hip
>> debugging.  I tossed out a troubleshooting suggestion, which I probably
>> shouldn't have done.  I was just looking for something that might be
>> different from this update compared to previous ones, to cause the
>> problem.  Looks like everybody but the original poster and me already
>> knew that steam.inf just doesn't update properly and it's a longstanding
>> problem.
>>
>> The update process...could use some improvement.  We know.  It will
>> happen when we convert the entire game to the new content delivery
>> system.
>>
>> Thanks,
>> - Fletch
>>
>> -Original Message-
>> From: hlds_linux-boun...@list.valvesoftware.com
>> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of
>> PharaohsPaw
>> Sent: Friday, December 16, 2011 9:05 AM
>> To: HLDS Linux
>> Subject: [hlds_linux] (ATTN: Valve) steam.inf missing and other
>> "incomplete update" problems
>>
>> Although I've said much of this already I'm making a separate post in
>> its own topic in hopes that Valve will give it some serious
>> consideration, and more importantly, do something about it to fix the
>> problem.  I am thankful that Valve staff does pay attention to this
>> mailing list.
>>
>> The subject of this post is a problem that has been around for a long
>> time.  I have been operating public gameservers off and on since 2006
>

Re: [hlds_linux] (ATTN: Valve) steam.inf missing and other "incomplete update" problems

[PharaohsPaw]

Hi Fletch,

No, it's OK.  Thanks for responding.

I do have to wonder if there is something I could, or SHOULD do
differently.  With folks like Steve who posted a few replies back
mentioning that he updates 145 servers and has never seen this problem
before - and that he doesn't use -verify_all either, it does make me
wonder what could possibly be wrong, or at least "fatally different" about
what our setup does.

The steam.inf file must update properly for some people, since Steve has
never seen a problem (and he has a lot more servers being updated also).

Steve how do your servers update?  Do you have -autoupdate on the command
line?  Do they just update when the map changes, or are you doing
something different such as one of the plugins that uses steamtools to
handle the master request restart?

I'd hate to imagine having to manually restart/update 145 servers. :)

I'm also wondering if maybe what I should do is edit the nemrun script to
put some kind of a delay in, so that when an update is detected (because
srcupdatecheck returned a 7 code), it waits a little while before it
actually begins the update process (calling steam to update the tree) --
so that even though we detect an update being released really quickly
after it hits, and knows it needs to start an update, it waits X number of
seconds first - to try to give extra time for the files to be pushed to
the masters before we start that update.  If the problem has anything to
do with waiting long enough for the update files to be propagated to any
master the steam binary is likely to hit to begin the update, this would
probably help.

Fletch is there any chance at all that the steam.inf file might just be
one of the last files to get placed onto the masters when update files are
loaded/replicated?  If so, then this could be another indicator that
nemrun just needs to wait a little longer before it starts an autoupdate.

Thanks,
PharaohsPaw

___
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] (ATTN: Valve) steam.inf missing and other "incomplete update" problems

[PharaohsPaw]

Although I've said much of this already I'm making a separate post in its
own topic in hopes that Valve will give it some serious consideration, and
more importantly, do something about it to fix the problem.  I am thankful
that Valve staff does pay attention to this mailing list.

The subject of this post is a problem that has been around for a long
time.  I have been operating public gameservers off and on since 2006 and
have seen this occur with some update releases pretty much since then.  I
am not the first person to say this happens, and I am also pretty sure
this is not the first time I had something to say about it here.

In short, the problem is incomplete updates.  It seems that the
(gamedir)/steam.inf file is the file most often left out of updates, but
sometimes other updated or new files are involved.  Sometimes (apparently)
files that an "updated" server will crash without are missed.

SCOPE OF PROBLEM
I should point out that I am specifically referring only to update
scenarios where the updater for a particular gameserver "tree" initiates
an update, pulls in files, AND RECEIVES A SUCCESSFUL "HLDS Installation Is
Up to Date" MESSAGE FROM THAT MASTER AND THE STEAM BINARY RESPONSIBLE FOR
UPDATING THE SERVER FILES EXITS WITH A 0 RETURN CODE when there are
actually files missing and the server cannot run properly afterwards as a
result.

The scenario in question also involves NOT using -verify_all among the
arguments passed to the steam binary to perform the update.

Whether the server in question is just using srcds_run with -autoupdate
among the command line arguments, or using nemrun or any other
properly-written script isn't important.

While it is possible to have incorrectly-written scripts to run and/or
update our servers, that isn't what I'm talking about here.  Nemrun and
other properly-written update scripts do not run "./steam -command update
-game tf -dir ." (or whatever) only once and ASSUME the update was
successful.  We can't do that because it is fairly common to get a
connection reset from whichever master we are pulling the update from
before it is complete.  It has to check the return code from the steam
binary doing the update, and if it isn't 0, you have to repeat until it IS
0.

Also, it needs to be understood by anyone at Valve investigating this
problem that neither nemrun, nor any other script (including your own
srcds_run with used with -autoupdate) that I'm talking about does anything
more than call the steam binary with "-command update".  Nemrun in
updatedaemon mode may have its own implementation of checking in with
steam to see if an update is needed, but it does comply with your
protocols, and even when it does start an update, it only does it because
your masters said a required update was available.  And it calls the same
steam binary to do the actual updating that srcds_run does.

Guess why the steam.inf file is so important?  This isn't specific to
nemrun, by the way.  It tells the dedicated server which version to report
to the steam masters.  So its contents (or existence) means everything to
that dedicated server when it checks in with the masters.  You could be
100% in sync with the latest dedicated server files, and edit steam.inf to
show an older version, and the next time your server checks in with the
masters it is going to tell you that you need to update.  And until your
steam.inf file has the same patch level/version that the masters think is
the latest required version, your server will keep telling you to restart
for the latest update.  The same is true if the file isn't there at all. 
So it's not just nemrun that needs this file.  It needs it for the same
reasons the gameserver itself does.

The nemrun scripts are out there for Valve and anybody else to look at. 
Please look at them before you say nemrun is the problem.  It isn't.

So what IS going on?  As far as I'm concerned we have a couple of
different issues here:

1. The steam binary can remove the existing steam.inf file while updating
a server, even if it doesn't have an updated one to replace it with.

2. The steam binary will exit with a 0 return code and claim that the HLDS
Installation is Up To Date when the server hasn't been fully updated.

Anyone seeing a pattern yet?

STEAM BINARY

Now, let's talk about distributing updates among your masters.  Here are a
couple questions anyone thinking about this rationally should ask:

1. Why does a master server tell you that an update is available if it
doesn't have ALL of the updated files yet?  If it doesn't have all the
updated files, it should not be telling you to restart your server UNTIL
IT DOES.

2. Why does the steam binary exit with a 0 RETURN CODE (successful) AND
EVEN TELL YOU 'HLDS Installation is Up To Date' if it doesn't have all the
files that got updated?


SUGGESTIONS
I don't have visibility of the inner workings of Valve's content
distribution system and I am not aware of whatever policies and procedures
you may have for rel

Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

>
> Regarding the update failures, what was $?
>
> That is, did the updater exit 0, or something else?
>
> My auto-update script checks to make sure that I get exit 0 from steam,
> or else it runs again up to four times before it gives up.  It is very
> common that it runs twice.
>
> I don't use nemrun myself, but I seem to remember his script doing a
> similar exit code check and re-running the update as necessary.
>
> If steam didn't exit 0, it didn't update.  If you don't know, then you
> should!
>
> Just do "echo $?" immediately and only immediately after the steam
> command finishes to find out the exit code.  If it's 0, that's good.  if
> it's something else, re-run the update.

nemrun DOES re-check.  The scripts are out there for anybody to look at,
including Valve and anyone else who wants to suggest it is doing something
wrong as an explanation for the problem.

I would imagine a lot of people on this list actually DO know about bash
using $? to store the return code from the last command.  I do and have
for a long time.  Here's a snip from one of my simpler "older days" update
scripts:


# update game function definition
game_update() {

./steam -command update -game "tf" -dir . -verify_all -retry

}

cd ~/tf2


# run update function once in case we get a zero return value on 1st try:
game_update

#echo "Return Code: $?"

## loop - we should keep doing this until we get a zero return
#
until [ $? -eq 0 ] ; do

game_update
done


The problem isn't that our scripts are doing the wrong thing.





>
> --
>
> This isn't the best bash, but whatever.  This is a snip, may be
> incomplete.
>
>while [ /bin/true ] ; do
>./steam -command update -game $GAME -dir ./$GAMEDIR -retry
>  UPDATEEXIT=$?
>  UPDATECOUNTER=$(( $UPDATECOUNTER + 1)) # counter increment
>  echo ""
>  echo "./steam update exit code was $UPDATEEXIT"
>  if [ "$UPDATEEXIT" = 0 ] ; then
>echo ""
>echo "Update completed.  Please start server if desired."
>break
>  else
>echo ""
>echo "Update did not succeed."
>if [ "$UPDATECOUNTER" -lt "5" ] ; then
>  echo "Try $UPDATECOUNTER failed, will try again..."
>  sleep 1
>  continue
>fi
>if [ "$UPDATECOUNTER" -eq "5" ] ; then
>  echo "Tried $UPDATECOUNTER times already.  Will not try again."
>  break
>fi
>  fi
>done
>
>
>
>
> John Schoenick wrote:
>> nemrun just calls hldsupdatetool with normal options.
>>
>> Your princess is in another castle.
>>
>> On 12/15/2011 08:32 PM, Fletcher Dunn wrote:
>>> PatchVersion=1.1.8.9
>>> ProductName=tf
>>> appID=440
>>>
>>> The file was definitely updated in the depots. I don't know why some
>>> people are not able to get it. You know there *is* something else that
>>> has changed other than our update: many of you are using a new
>>> up-to-date check script. Nothing on our end has changed with regard to
>>> how we distribute this file. None of the Valve dedicated servers had a
>>> problem receiving it.
>>>
>>> It looks like there is a problem where old servers are still allowed
>>> to be listed, if they were logged in before the update. That may be
>>> adding to the confusion.
>>>
>>> - Fletch
>
> --
> # 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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

that isn't nemrun's fault.  Remember, it's only doing a "steam -command
update" command.

I think they released more files.  Or, it is possible to be informed of an
update available before whichever master you're talking to has all of them
to feed you.

All 4 of my servers are bakc up now after this last bunch of files
finished coming in.


> My -verify_all just finished (it took an *hour* before it started
> downloading anything) and judging from what it's downloading, nemrun
> 1.8.5 isn't properly detecting whether the update succeeded or failed...
> because it looks like my server didn't grab the majority of any of the
> packages.
>
> That is, unless
> "[Thu Dec 15 21:27:53 CST 2011] :: Update tool completed, but master
> servers tell us we're still out of date; Retrying"
> is supposed to appear when the update *fails*
>
> My segfaulting went away after it basically downloaded everything in the
> update.
>
> On 12/15/2011 11:59 PM, John Schoenick wrote:
>> nemrun just calls hldsupdatetool with normal options.
>>
>> Your princess is in another castle.
>>
>> On 12/15/2011 08:32 PM, Fletcher Dunn wrote:
>>> PatchVersion=1.1.8.9
>>> ProductName=tf
>>> appID=440
>>>
>>> The file was definitely updated in the depots.  I don't know why some
>>> people are not able to get it.  You know there *is* something else
>>> that has changed other than our update: many of you are using a new
>>> up-to-date check script.  Nothing on our end has changed with regard
>>> to how we distribute this file.  None of the Valve dedicated servers
>>> had a problem receiving it.
>>>
>>> It looks like there is a problem where old servers are still allowed
>>> to be listed, if they were logged in before the update.  That may be
>>> adding to the confusion.
>>>
>>> - Fletch
>>>
>>> -Original Message-
>>> From: hlds_linux-boun...@list.valvesoftware.com
>>> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Kyle
>>> Sanderson
>>> Sent: Thursday, December 15, 2011 8:25 PM
>>> To: Half-Life dedicated Linux server mailing list
>>> Subject: Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source,
>>> Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released
>>>
>>> While I no longer have a steam.inf on my client, it's there on my
>>> Linux CS:S servers.
>>>
>>> Kyle.
>>>
>>> On Thu, Dec 15, 2011 at 8:22 PM, Russell
>>> Smithwrote:
>>>
 Similar situation here:

 Thu Dec 15 19:49:47 PST 2011: Server restart in 10 seconds Updating
 server using Steam.
 Checking bootstrapper version ...
 removing stale semaphore last operated on by process 24128 with name
 0eBlobRegistryMutex_**3D2F1DA4500B9E01D073D329D38559**A4

 Updating Installation
 Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
 progress"
 CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
 deferrals.
 CAsyncIOManager: 48 single object sleeps, 0 multi object sleeps

 CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
 alertable sleeps Thu Dec 15 19:58:09 PST 2011: Steam Update failed,
 ignoring.

 Running a benchmark to measure system clock frequency...
 Finished RDTSC test. To prevent the startup delay from this benchmark,
 set the environment variable RDTSC_FREQUENCY to 2799.00 on this
 system.
 This value is dependent upon the CPU clock speed and architecture and
 should be determined separately for each server. The use of this
 mechanism for timing can be disabled by setting RDTSC_FREQUENCY to
 'disabled'.

 Using breakpad minidump system
 Using breakpad crash handler

 Console initialized.
 Segmentation fault
 Add "-debug" to the /home/tf2server/hlds2/**orangebox/srcds_run
 command line to generate a debug.log to help with solving this problem



 On 12/15/2011 8:18 PM, Tyler Davies wrote:

> Checking bootstrapper version ...
> removing stale semaphore last operated on by process 28342 with name
> 0eBlobRegistryMutex_**82766499A575F9E1375FC8CE5C5066**73
> Updating Installation
> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
> progress"
> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
> deferrals.
> CAsyncIOManager: 50 single object sleeps, 0 multi object sleeps
> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
> alertable sleeps Thu Dec 15 22:00:18 CST 2011: Steam Update failed,
> ignoring.
> Running a benchmark to measure system clock frequency...
> Finished RDTSC test. To prevent the startup delay from this
> benchmark, set the environment variable RDTSC_FREQUENCY to
> 3391.00 on this system.
> This value is dependent upon the CPU clock speed and architecture and
> should be determined separately for each server. The use of this
> mechanism for timing can be disabled by setting RDTSC_FREQUENCY to
> 'disable

Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

Yeah, I just forced another update by editing the steam.inf back to
1.1.8.8 and starting up my -verify_all version of my nemrun updater
script.  It's pulling a bunch more files in now...

> After running the command again all my boxes are running fine with the
> latest snapshots of sourcemod and metamod source.
>
> On Thu, Dec 15, 2011 at 11:59 PM, John Schoenick
> wrote:
>
>> nemrun just calls hldsupdatetool with normal options.
>>
>> Your princess is in another castle.
>>
>>
>> On 12/15/2011 08:32 PM, Fletcher Dunn wrote:
>>
>>> PatchVersion=1.1.8.9
>>> ProductName=tf
>>> appID=440
>>>
>>> The file was definitely updated in the depots.  I don't know why some
>>> people are not able to get it.  You know there *is* something else that
>>> has
>>> changed other than our update: many of you are using a new up-to-date
>>> check
>>> script.  Nothing on our end has changed with regard to how we
>>> distribute
>>> this file.  None of the Valve dedicated servers had a problem receiving
>>> it.
>>>
>>> It looks like there is a problem where old servers are still allowed to
>>> be listed, if they were logged in before the update.  That may be
>>> adding to
>>> the confusion.
>>>
>>> - Fletch
>>>
>>> -Original Message-
>>> From:
>>> hlds_linux-bounces@list.**valvesoftware.com[mailto:
>>> hlds_linux-bounces@**list.valvesoftware.com]
>>> On Behalf Of Kyle Sanderson
>>> Sent: Thursday, December 15, 2011 8:25 PM
>>> To: Half-Life dedicated Linux server mailing list
>>> Subject: Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day
>>> of
>>> Defeat: Source and Half-Life 2: Deathmatch Updates Released
>>>
>>> While I no longer have a steam.inf on my client, it's there on my Linux
>>> CS:S servers.
>>>
>>> Kyle.
>>>
>>> On Thu, Dec 15, 2011 at 8:22 PM, Russell
>>> Smith>> us >wrote:
>>>
>>>  Similar situation here:

 Thu Dec 15 19:49:47 PST 2011: Server restart in 10 seconds Updating
 server using Steam.
 Checking bootstrapper version ...
 removing stale semaphore last operated on by process 24128 with name
 0eBlobRegistryMutex_3D2F1DA4500B9E01D073D329D38559A4

 Updating Installation
 Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
 progress"
 CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
 deferrals.
 CAsyncIOManager: 48 single object sleeps, 0 multi object sleeps

 CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
 alertable sleeps Thu Dec 15 19:58:09 PST 2011: Steam Update failed,
 ignoring.

 Running a benchmark to measure system clock frequency...
 Finished RDTSC test. To prevent the startup delay from this benchmark,
 set the environment variable RDTSC_FREQUENCY to 2799.00 on this
 system.
 This value is dependent upon the CPU clock speed and architecture and
 should be determined separately for each server. The use of this
 mechanism for timing can be disabled by setting RDTSC_FREQUENCY to
 'disabled'.

 Using breakpad minidump system
 Using breakpad crash handler

 Console initialized.
 Segmentation fault
 Add "-debug" to the /home/tf2server/hlds2/orangebox/srcds_run
 command line to generate a debug.log to help with solving this problem



 On 12/15/2011 8:18 PM, Tyler Davies wrote:

  Checking bootstrapper version ...
> removing stale semaphore last operated on by process 28342 with name
> 0eBlobRegistryMutex_82766499A575F9E1375FC8CE5C506673
> Updating Installation
> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
> progress"
> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
> deferrals.
> CAsyncIOManager: 50 single object sleeps, 0 multi object sleeps
> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
> alertable sleeps Thu Dec 15 22:00:18 CST 2011: Steam Update failed,
> ignoring.
> Running a benchmark to measure system clock frequency...
> Finished RDTSC test. To prevent the startup delay from this
> benchmark, set the environment variable RDTSC_FREQUENCY to
> 3391.00
> on this system.
> This value is dependent upon the CPU clock speed and architecture and
> should be determined separately for each server. The use of this
> mechanism for timing can be disabled by setting RDTSC_FREQUENCY to
> 'disabled'.
> Using breakpad minidump system
> Using breakpad crash handler
>
> Console initialized.
> Segmentation fault (core dumped)
> BFD: Warning: /home/servuser/srcds/orangebox/core is truncated:
> expected
> core file size>= 41066496, found: 12414976.
> Cannot access memory at address 0xf77e9908 Cannot access memory at
> address 0xf77e9908 Cannot access memory at address 0xf77e9908
>
> warning: the debug information found in "/lib/ld-2.12.1.so" does not
> match "/li

Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

Of course the bigger problem is segfaulting on startup, which is
apparently happening for people who didn't have other problems.  That's
probably where Valve needs to focus on right now, but it would be really
great if somebody could look into this steam.inf issue and fix it once
and for all.  I don't think nemrun is the only thing that depends on the
contents of that file to report the local game version to the masters. 
(simple test: go edit yours to something lower than latest and do a
heartbeat, and see what you get back)

> This has all happened before.  (isn't that a line out of a movie or
> something?)
>
> As I said before, I used to get this problem on some of the updates even
> before I started using nemrun.  I only started using nemrun a little over
> a year ago.  I used to get broken updates before that too.  (and I have
> been running valve dedicated servers off and on since fall of 2006).
>
> I don't know why it happens.  I do not believe, however, that nemrun is
> the problem.  When the actual *updating* happens, nemrun is simply issuing
> a "steam -command update" command.  The script doesn't do anything else
> until the update has exited.
>
> It has beena while since I have really looked into this or searched around
> the net and the mailing lists for others having the problem, so I am
> probably fuzzy on the details.  But if I remember correctly, I believe the
> distinction comes in whether the steam.inf file is marked as an updated
> file or not, along with the other new or updated files with that update.
> And so whether you get a new steam.inf file may all have to do with
> whether you did a "quick" update (./steam -command update) or a "full"
> update (./steam -command update -verify_all blah blah blah).
>
> Make sense?
>
> I do know that running a -verify_all update does get the latest steam.inf,
> for exactly the same reason that you get one when you are starting a new
> install tree from scratch with the ./steam -command update.  Because it
> will install the entire set of files for the dedicated server if it has to
> to get you a copy of everything you're supposed to have.
>
> Whereas just doing a quick update doesn't get you the updated steam.inf
> file, if it isn't marked as an updated file.  that is what I think the
> problem is.  And it has happened a lot of times over the years I have
> tortured myself trying to have good-running Valve gameservers.
>
>
>
>
>>
>> It looks like there is a problem where old servers are still allowed to
>> be
>> listed, if they were logged in before the update.  That may be adding to
>> the confusion.
>>
>> - Fletch
>>
>> -Original Message-
>> From: hlds_linux-boun...@list.valvesoftware.com
>> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Kyle
>> Sanderson
>> Sent: Thursday, December 15, 2011 8:25 PM
>> To: Half-Life dedicated Linux server mailing list
>> Subject: Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day
>> of
>> Defeat: Source and Half-Life 2: Deathmatch Updates Released
>>
>> While I no longer have a steam.inf on my client, it's there on my Linux
>> CS:S servers.
>>
>> Kyle.
>>
>> On Thu, Dec 15, 2011 at 8:22 PM, Russell Smith
>> wrote:
>>
>>> Similar situation here:
>>>
>>> Thu Dec 15 19:49:47 PST 2011: Server restart in 10 seconds Updating
>>> server using Steam.
>>> Checking bootstrapper version ...
>>> removing stale semaphore last operated on by process 24128 with name
>>> 0eBlobRegistryMutex_**3D2F1DA4500B9E01D073D329D38559**A4
>>>
>>> Updating Installation
>>> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
>>> progress"
>>> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
>>> deferrals.
>>> CAsyncIOManager: 48 single object sleeps, 0 multi object sleeps
>>>
>>> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
>>> alertable sleeps Thu Dec 15 19:58:09 PST 2011: Steam Update failed,
>>> ignoring.
>>>
>>> Running a benchmark to measure system clock frequency...
>>> Finished RDTSC test. To prevent the startup delay from this benchmark,
>>> set the environment variable RDTSC_FREQUENCY to 2799.00 on this
>>> system.
>>> This value is dependent upon the CPU clock speed and architecture and
>>> should be determined separately for each server. The use of this
>>> mechanism for timing can be disabled by setting RDTSC_FREQUENCY to
>>> 'disabled'.
>>>
>>> Using breakpad minidump system
>>> Using breakpad crash handler
>>>
>>> Console initialized.
>>> Segmentation fault
>>> Add "-debug" to the /home/tf2server/hlds2/**orangebox/srcds_run
>>> command line to generate a debug.log to help with solving this problem
>>>
>>>
>>>
>>> On 12/15/2011 8:18 PM, Tyler Davies wrote:
>>>
 Checking bootstrapper version ...
 removing stale semaphore last operated on by process 28342 with name
 0eBlobRegistryMutex_**82766499A575F9E1375FC8CE5C5066**73
 Updating Installation
 Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
>>

Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

> PatchVersion=1.1.8.9
> ProductName=tf
> appID=440
>
> The file was definitely updated in the depots.  I don't know why some
> people are not able to get it.  You know there *is* something else that
> has changed other than our update: many of you are using a new up-to-date
> check script.  Nothing on our end has changed with regard to how we
> distribute this file.  None of the Valve dedicated servers had a problem
> receiving it.

This has all happened before.  (isn't that a line out of a movie or
something?)

As I said before, I used to get this problem on some of the updates even
before I started using nemrun.  I only started using nemrun a little over
a year ago.  I used to get broken updates before that too.  (and I have
been running valve dedicated servers off and on since fall of 2006).

I don't know why it happens.  I do not believe, however, that nemrun is
the problem.  When the actual *updating* happens, nemrun is simply issuing
a "steam -command update" command.  The script doesn't do anything else
until the update has exited.

It has beena while since I have really looked into this or searched around
the net and the mailing lists for others having the problem, so I am
probably fuzzy on the details.  But if I remember correctly, I believe the
distinction comes in whether the steam.inf file is marked as an updated
file or not, along with the other new or updated files with that update. 
And so whether you get a new steam.inf file may all have to do with
whether you did a "quick" update (./steam -command update) or a "full"
update (./steam -command update -verify_all blah blah blah).

Make sense?

I do know that running a -verify_all update does get the latest steam.inf,
for exactly the same reason that you get one when you are starting a new
install tree from scratch with the ./steam -command update.  Because it
will install the entire set of files for the dedicated server if it has to
to get you a copy of everything you're supposed to have.

Whereas just doing a quick update doesn't get you the updated steam.inf
file, if it isn't marked as an updated file.  that is what I think the
problem is.  And it has happened a lot of times over the years I have
tortured myself trying to have good-running Valve gameservers.




>
> It looks like there is a problem where old servers are still allowed to be
> listed, if they were logged in before the update.  That may be adding to
> the confusion.
>
> - Fletch
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Kyle
> Sanderson
> Sent: Thursday, December 15, 2011 8:25 PM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of
> Defeat: Source and Half-Life 2: Deathmatch Updates Released
>
> While I no longer have a steam.inf on my client, it's there on my Linux
> CS:S servers.
>
> Kyle.
>
> On Thu, Dec 15, 2011 at 8:22 PM, Russell Smith
> wrote:
>
>> Similar situation here:
>>
>> Thu Dec 15 19:49:47 PST 2011: Server restart in 10 seconds Updating
>> server using Steam.
>> Checking bootstrapper version ...
>> removing stale semaphore last operated on by process 24128 with name
>> 0eBlobRegistryMutex_**3D2F1DA4500B9E01D073D329D38559**A4
>>
>> Updating Installation
>> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
>> progress"
>> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0 deferrals.
>> CAsyncIOManager: 48 single object sleeps, 0 multi object sleeps
>>
>> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
>> alertable sleeps Thu Dec 15 19:58:09 PST 2011: Steam Update failed,
>> ignoring.
>>
>> Running a benchmark to measure system clock frequency...
>> Finished RDTSC test. To prevent the startup delay from this benchmark,
>> set the environment variable RDTSC_FREQUENCY to 2799.00 on this
>> system.
>> This value is dependent upon the CPU clock speed and architecture and
>> should be determined separately for each server. The use of this
>> mechanism for timing can be disabled by setting RDTSC_FREQUENCY to
>> 'disabled'.
>>
>> Using breakpad minidump system
>> Using breakpad crash handler
>>
>> Console initialized.
>> Segmentation fault
>> Add "-debug" to the /home/tf2server/hlds2/**orangebox/srcds_run
>> command line to generate a debug.log to help with solving this problem
>>
>>
>>
>> On 12/15/2011 8:18 PM, Tyler Davies wrote:
>>
>>> Checking bootstrapper version ...
>>> removing stale semaphore last operated on by process 28342 with name
>>> 0eBlobRegistryMutex_**82766499A575F9E1375FC8CE5C5066**73
>>> Updating Installation
>>> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
>>> progress"
>>> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
>>> deferrals.
>>> CAsyncIOManager: 50 single object sleeps, 0 multi object sleeps
>>> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
>>> alertab

Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

OK here is the contents of the new steam.inf file (after first update
tonight):

PatchVersion=1.1.8.9
ProductName=tf
appID=440


My "off to the side" instance got far enough along in its -verify_all to
have pulled in the new steam.inf file, so I copied it into place on the
live servers tree.

Now I am caught up with everyone else whose games just segfault on them at
start up. :)

Since we've already heard from at least one person who pulled out all of
their plugins, I'm not going to bother pulling metamod and sourcemod out.

If I can get a core file (or somebody else can) maybe Valve can use it to
figure out what they broke and get us another update out.



> While I no longer have a steam.inf on my client, it's there on my Linux
> CS:S servers.
>
> Kyle.
>
> On Thu, Dec 15, 2011 at 8:22 PM, Russell Smith
> wrote:
>
>> Similar situation here:
>>
>> Thu Dec 15 19:49:47 PST 2011: Server restart in 10 seconds
>> Updating server using Steam.
>> Checking bootstrapper version ...
>> removing stale semaphore last operated on by process 24128 with name
>> 0eBlobRegistryMutex_**3D2F1DA4500B9E01D073D329D38559**A4
>>
>> Updating Installation
>> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
>> progress"
>> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0 deferrals.
>> CAsyncIOManager: 48 single object sleeps, 0 multi object sleeps
>>
>> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
>> alertable sleeps
>> Thu Dec 15 19:58:09 PST 2011: Steam Update failed, ignoring.
>>
>> Running a benchmark to measure system clock frequency...
>> Finished RDTSC test. To prevent the startup delay from this benchmark,
>> set
>> the environment variable RDTSC_FREQUENCY to 2799.00 on this system.
>> This value is dependent upon the CPU clock speed and architecture and
>> should be determined separately for each server. The use of this
>> mechanism
>> for timing can be disabled by setting RDTSC_FREQUENCY to 'disabled'.
>>
>> Using breakpad minidump system
>> Using breakpad crash handler
>>
>> Console initialized.
>> Segmentation fault
>> Add "-debug" to the /home/tf2server/hlds2/**orangebox/srcds_run command
>> line to generate a debug.log to help with solving this problem
>>
>>
>>
>> On 12/15/2011 8:18 PM, Tyler Davies wrote:
>>
>>> Checking bootstrapper version ...
>>> removing stale semaphore last operated on by process 28342 with name
>>> 0eBlobRegistryMutex_**82766499A575F9E1375FC8CE5C5066**73
>>> Updating Installation
>>> Failed to connect to 72.165.61.190:27037, errno 115 "Operation now in
>>> progress"
>>> CAsyncIOManager: 0 threads terminating.  0 reads, 0 writes, 0
>>> deferrals.
>>> CAsyncIOManager: 50 single object sleeps, 0 multi object sleeps
>>> CAsyncIOManager: 0 single object alertable sleeps, 0 multi object
>>> alertable
>>> sleeps
>>> Thu Dec 15 22:00:18 CST 2011: Steam Update failed, ignoring.
>>> Running a benchmark to measure system clock frequency...
>>> Finished RDTSC test. To prevent the startup delay from this benchmark,
>>> set
>>> the environment variable RDTSC_FREQUENCY to 3391.00 on this system.
>>> This value is dependent upon the CPU clock speed and architecture and
>>> should be determined separately for each server. The use of this
>>> mechanism
>>> for timing can be disabled by setting RDTSC_FREQUENCY to 'disabled'.
>>> Using breakpad minidump system
>>> Using breakpad crash handler
>>>
>>> Console initialized.
>>> Segmentation fault (core dumped)
>>> BFD: Warning: /home/servuser/srcds/**orangebox/core is truncated:
>>> expected
>>> core file size>= 41066496, found: 12414976.
>>> Cannot access memory at address 0xf77e9908
>>> Cannot access memory at address 0xf77e9908
>>> Cannot access memory at address 0xf77e9908
>>>
>>> warning: the debug information found in "/lib/ld-2.12.1.so" does not
>>> match
>>> "/lib/ld-linux.so.2" (CRC mismatch).
>>>
>>
>> __**_
>> 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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

> I didn't have any issues with steam.inf going away.
>
Would you be so kind as to post the contents of yours, then?

thanks :)  I know of at least 4 of us now who would love to see it so we
can try to get ours back up. :)

> On 12/15/2011 11:12 PM, PharaohsPaw wrote:
>> So let's see, that makes me and 2 other server operators now.  Either
>> all
>> 3 of us are smoking crack or maybe, just maybe, the update didn't come
>> with a steam.inf file
>>
>> But, it doesn't sound like it was a very good update anyway, can't blame
>> plugins/addons if none are loaded.
>>
>>
>>
>>> Bummer, i can't even play TF2 through steam. Says the game is
>>> currently unavailable :(. And now the servers are to busy to handle my
>>> request.
>>>
>>> steam.inf before update:
>>> PatchVersion=1.1.8.8
>>> ProductName=tf
>>> appID=440
>>>
>>> steam.inf after update:
>>> no file can be found!
>>>
>>>
>>> On Thu, Dec 15, 2011 at 10:56 PM, Ross Bemrose
>>> wrote:
>>>
>>>> gameserver@ocrtf2:~/orangebox/**tf$ locate steam.inf
>>>> /home/gameserver/event/**orangebox/tf/steam.inf
>>>> /home/gameserver/orangebox/tf/**steam.inf
>>>> gameserver@ocrtf2:~/orangebox/**tf$ more
>>>> /home/gameserver/orangebox/tf/**
>>>> steam.inf
>>>> /home/gameserver/orangebox/tf/**steam.inf: No such file or directory
>>>>
>>>> So, the file was basically deleted by today's update.
>>>>
>>>>
>>>> On 12/15/2011 10:54 PM, PharaohsPaw wrote:
>>>>
>>>>> Something did, as my server is segfaulting on start.
>>>>>> On 12/15/2011 10:46 PM, Violent Crimes wrote:
>>>>>>
>>>>>>> Anyone know if sourcemod offsets changed?
>>>>>>>
>>>>>>>   If one of you guys that got an update successfully woudln't mind
>>>>> posting
>>>>> the contents of your updated tf2/orangebox/tf/steam.inf file, I am
>>>>> willing
>>>>> to try to help figure out what this update broke with
>>>>> metamod/sourcemod
>>>>> (assuming you guys are running them).
>>>>>
>>>>> I'm no Bailopan but I know a few things about them. :)
>>>>>
>>>>> __**_
>>>>> To unsubscribe, edit your list preferences, or view the list
>>>>> archives,
>>>>> please visit:
>>>>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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<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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

> This can happen if you interrupt the update process. Are you sure that's
> not what happened?

The short version is, no, I didn't interrupt the update.  I've been around
this block a few times. :)

all of the actual game servers went down before nemrun started pulling
update files in.  I can attest to it bcause I have a screen full of screen
sessions that the games all went down in and sat there so nemrun could
update the game files.

Nemrun (the update daemon instance) creates a lock file.  Nothing fancy,
just a file that each of the gameservers (also running nemrun as an srcds
launcher script rather than srcds_run) knows to look for.  As long as the
lock file is there the game will not start back up.  because the script
holds them there without the game running.  This allows nemrun the updater
daemon to call steam to update the game files without anything else
messing with them while it works.



___
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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

So let's see, that makes me and 2 other server operators now.  Either all
3 of us are smoking crack or maybe, just maybe, the update didn't come
with a steam.inf file

But, it doesn't sound like it was a very good update anyway, can't blame
plugins/addons if none are loaded.



> Bummer, i can't even play TF2 through steam. Says the game is
> currently unavailable :(. And now the servers are to busy to handle my
> request.
>
> steam.inf before update:
> PatchVersion=1.1.8.8
> ProductName=tf
> appID=440
>
> steam.inf after update:
> no file can be found!
>
>
> On Thu, Dec 15, 2011 at 10:56 PM, Ross Bemrose 
> wrote:
>
>> gameserver@ocrtf2:~/orangebox/**tf$ locate steam.inf
>> /home/gameserver/event/**orangebox/tf/steam.inf
>> /home/gameserver/orangebox/tf/**steam.inf
>> gameserver@ocrtf2:~/orangebox/**tf$ more
>> /home/gameserver/orangebox/tf/**
>> steam.inf
>> /home/gameserver/orangebox/tf/**steam.inf: No such file or directory
>>
>> So, the file was basically deleted by today's update.
>>
>>
>> On 12/15/2011 10:54 PM, PharaohsPaw wrote:
>>
>>> Something did, as my server is segfaulting on start.
>>>>
>>>> On 12/15/2011 10:46 PM, Violent Crimes wrote:
>>>>
>>>>> Anyone know if sourcemod offsets changed?
>>>>>
>>>>>  If one of you guys that got an update successfully woudln't mind
>>> posting
>>> the contents of your updated tf2/orangebox/tf/steam.inf file, I am
>>> willing
>>> to try to help figure out what this update broke with metamod/sourcemod
>>> (assuming you guys are running them).
>>>
>>> I'm no Bailopan but I know a few things about them. :)
>>>
>>> __**_
>>> To unsubscribe, edit your list preferences, or view the list archives,
>>> please visit:
>>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<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<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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

> Something did, as my server is segfaulting on start.
>
> On 12/15/2011 10:46 PM, Violent Crimes wrote:
>> Anyone know if sourcemod offsets changed?
>>

If one of you guys that got an update successfully woudln't mind posting
the contents of your updated tf2/orangebox/tf/steam.inf file, I am willing
to try to help figure out what this update broke with metamod/sourcemod
(assuming you guys are running them).

I'm no Bailopan but I know a few things about them. :)

___
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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

> What problem are you experiencing exactly? The update for each game
> contains an updated steam.inf file. I'm not sure why you think it doesn't

steam.inf file is no longer present in tree after update.  Everything else
is there, and the first few loop-throughs of nemrun (auto-updater util
script) showed info from masters saying HLDS Installation is Up To Date
(the first run-through got the updated files).  ie, the update completed.

but because the steam.inf file is missing now, when the server starts back
up after the update, it still gets an out of date warning.  Well, nemrun
does, and thus it gets stuck in a loop of updates until a steam.inf file
comes along.

I suppose it is possible that MAYBE you could blame nemrun for eating the
updated steam.inf file, but I doubt it.  I've seen updates come out
without a steam.inf file before, even before I started using nemrun.

I will try a separate/safe tree I have off to the side and see if I can
manage to pick up the updated steam.inf file with it, then I can drop it
into the live gameservers tree if I am so lucky.

Thanks for the response

>
> -Eric
>
>
> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of
> PharaohsPaw
> Sent: Thursday, December 15, 2011 7:33 PM
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] Team Fortress 2, Counter-Strike: Source, Day of
> Defeat: Source and Half-Life 2: Deathmatch Updates Released
>
>> Required updates are now available for Team Fortress 2, Counter-Strike:
>> Source, Day of Defeat: Source and Half-Life 2: Deathmatch.  The specific
>> changes include:
>
> They just pushed it out, but guess what...
>
> YOU FORGOT TO RELEASE AN UPDATED STEAM.INF FILE WITH THE UPDATE AGAIN
>
> Thus forcing a -verify_all and who knows how long before our servers will
> be playable because every server on the planet with awake admins or
> auto-updaters is trying to update right now
>
> Valve, PLEASE put UPDATE THE STEAM.INF on your release checklist.
>
> It's such a shame that one tiny little file, one I could probably hack
> together myself if I knew what the values in it were supposed to be with
> this update, is the only reason our servers arent back up already with
> players on it.
>
>
>
>
> ___
> 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] Team Fortress 2, Counter-Strike: Source, Day of Defeat: Source and Half-Life 2: Deathmatch Updates Released

[PharaohsPaw]

> Required updates are now available for Team Fortress 2, Counter-Strike:
> Source, Day of Defeat: Source and Half-Life 2: Deathmatch.  The specific
> changes include:

They just pushed it out, but guess what...

YOU FORGOT TO RELEASE AN UPDATED STEAM.INF FILE WITH THE UPDATE AGAIN

Thus forcing a -verify_all and who knows how long before our servers will
be playable because every server on the planet with awake admins or
auto-updaters is trying to update right now

Valve, PLEASE put UPDATE THE STEAM.INF on your release checklist.

It's such a shame that one tiny little file, one I could probably hack
together myself if I knew what the values in it were supposed to be with
this update, is the only reason our servers arent back up already with
players on it.




___
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] It's beginning to look a lot like Smissmas

[PharaohsPaw]

They just pushed it out, but guess what...

YOU FORGOT TO RELEASE AN UPDATED STEAM.INF FILE WITH THE UPDATE AGAIN

Thus forcing a -verify_all and who knows how long before our servers will
be playable because every server on the planet with awake admins or
auto-updaters is trying to update right now

Valve, PLEASE put UPDATE THE STEAM.INF on your release checklist.



> We'll know when we know, if you get my drift. Be cool.
> ___
> 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] Team Fortress 2 Update Available

[PharaohsPaw]

> Do you have tried '-retry'?


>> in an update loop, you end up having to do a -verify_all, and then for
>> the
>> next many hours your "-verify_all -retry" script loops and loops and
>> loops
>> because Valve's master servers keep hanging up the phone on you with:

Considering the above 3 lines of my OP, what would your guess be? :)

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

Re: [hlds_linux] orangebox exploit (Andres Pozos)

[PharaohsPaw]

> does this not work?
> iptables -I INPUT -p udp -m length --length 0 -j DROP


I was doing some reading about this last night.  One of our servers filled
up right after one of the updates (we use nemrun so we tend to get the
updates really quick) -- but after 15-20 minutes the server crashed.

Knowing now (or at least word seems to be) that there was apparently a
problem with mp_falldamage being enabled causing a server crash as a
result of one of these updates, I'm less inclined to think it was someone
exploiting this server, however I did read over those posts linked a few
posts back in this thread, and just in case, I added this firewall rule to
my "udp coming in from the external interface" chain:

iptables -A INPUT -p udp --dport 27015:27034 -m length --length 0:28 -j DROP

ahead of the -j ACCEPT rule that accepts UDP traffic on those ports.

The idea being that for any of the destination ports 27015-27034 (the
range of ports any of our gameservers run on plus a few extras etc.), any
UDP packets 28 bytes or smaller will be dropped.

I did also see someone mention using --length 0:32, meaning any packet 32
bytes or smaller, but not 100% sure that is OK.

Anyway, the syntax above shows how you can have 1 rule that covers all of
the ports for your servers (adjust 27015 and 27034 as needed for your
setup) and a RANGE of sizes, iptables seemed happy enough with the syntax
here.

PharaohsPaw

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

Re: [hlds_linux] Team Fortress 2 Update Available

[PharaohsPaw]

> On 3/10/2011 5:09 PM, EDAC wrote:
>> Yes, that is fixed in this update (thank you, unannounced mandatory
>> update
>> from 30 minutes ago).
>
> There have been three mandatory TF2 updates today so far, but only one
> mentioned on the list here. I hope this is going to be all of them
> tonight..

Don't you just love it when due to a failed update and then getting stuck
in an update loop, you end up having to do a -verify_all, and then for the
next many hours your "-verify_all -retry" script loops and loops and loops
because Valve's master servers keep hanging up the phone on you with:

Checking/Installing 'Base Source Shared Sounds' version 4


Checking/Installing 'OB Linux Dedicated Server' version 84


Connection Reset, errno 104 "Connection reset by peer"   <

right before it would have finished?

Valve please for the love of all that is holy, can you do something about
this?



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

Re: [hlds_linux] l4d2 update came out..

[PharaohsPaw]

>> to the consoles.  Glad I got nemrun modded to work w/L4D2 since running
>> a
>> "stock" dedicated server tree with "-autoupdate" clearly isn't enough
>> foo
>> to truly get automatic updates. :)

> Apparently you're not aware of how Valve's autoupdate works.  Valve's
> autoupdate only kicks in when the server changes maps.  This is to
> prevent it from kicking players off the server.

Dude, I've been running Valve dedicated server games on Linux machines for
over 4 years.  Whether YOU think so or not, I actually do understand
fairly well how updates work.  Do you really have nothing better to do
than piss in my corn flakes?

I was trying to make a point, nothing more.  Without something like
nemrun, these servers aren't going to update until a map change happens. 
Since nobody was on the servers at the time, when exactly do you suppose
that "map change" is going to happen?

I'll leave that as an exercise for you to figure out or recite since you
know so much.  I already know the answer.  Me, I'd rather have the servers
update BEFORE then.

Next time I fix something like this maybe I'll just keep it to myself.

DIAF,
PharaohsPaw



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

Re: [hlds_linux] l4d2 update came out..

[PharaohsPaw]

> Left 4 Dead 2

yep just saw all my l4d2 servers (which i've not modded to use nemrun yet)
spamming:

MasterRequestRestart
Your server will be restarted on map change.
MasterRequestRestart
Your server will be restarted on map change.
MasterRequestRestart
Your server will be restarted on map change.

to the consoles.  Glad I got nemrun modded to work w/L4D2 since running a
"stock" dedicated server tree with "-autoupdate" clearly isn't enough foo
to truly get automatic updates. :)

And thank you Valve for putting this update out, gives me perfect
opportunity to verify nemrun is doing the right thing with a real update.
:)

Cheers,
PharaohsPaw


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

Re: [hlds_linux] Anyone successfully using nemrun w/left4dead2?

[PharaohsPaw]

> So, time to brush the dust off my 2 brain cells and figure out how to
> modify srcupdatecheck's python code to parse an L4D2-style steam.inf file
> (since it seems unlikely that Valve is going to modify it to suit us... :)
>
> If anybody cares to assist/suggest, feel free.  If I come up with
> something that works I'll post it.

This seems to fix it for me.  I tested it with Valve's apparent steam.inf
format for L4D2, the usual (CS:S and TF2) format, and also a "bad"
steam.inf that was missing a PatchVersion= line.

This is a patch in diff -ur format:

--- srcupdatecheck.orig 2010-12-17 09:09:33.261601054 -0500
+++ srcupdatecheck  2010-12-17 10:54:07.159473612 -0500
@@ -51,8 +51,13 @@
print "File \"%s\" does not exist!" % sys.argv[1]
sys.exit(-1)

-verstring = steaminf.readline()
-verre = re.search('PatchVersion=([^\r\n]+)', verstring)
+for verstring in iter(steaminf.readline, "PatchVersion="):
+   if verstring:
+   verre = re.search('PatchVersion=([^\r\n]+)', verstring)
+   if verre:
+   break
+   else:
+   break

 if not verre:
print "Invalid steam.inf file."
@@ -64,8 +69,13 @@
 # Read ProductName
 #

-prodstring = steaminf.readline()
-prodre = re.search('ProductName=([^\r\n]+)', prodstring)
+for prodstring in iter(steaminf.readline, "ProductName="):
+   if prodstring:
+   prodre = re.search('ProductName=([^\r\n]+)', prodstring)
+   if prodre:
+   break
+   else:
+   break

 if not prodre:
print "Invalid steam.inf file."
@@ -77,8 +87,13 @@
 # And AppID
 #

-appstring = steaminf.readline()
-appre = re.search('appID=([^\r\n]+)', appstring)
+for appstring in iter(steaminf.readline, "appID="):
+   if appstring:
+   appre = re.search('appID=([^\r\n]+)', appstring)
+   if appre:
+   break
+   else:
+   break

 if not appre:
print "Invalid steam.inf file."





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

Re: [hlds_linux] Anyone successfully using nemrun w/left4dead2?

[PharaohsPaw]

>> Maybe I need to use setmaster* cmds in the running l4d2's to see which
>> masters they are talking to and try modifying srcupdatecheck to one or
>> more of those masters instead.  It's just a guess but maybe L4D2 servers
>> need to talk to different masters to do version checking queries.
>>
>> Any ideas, Nephyrin?
>
> OK, just for shi*ts & giggles I tried running srcupdatecheck manually from
> the command line.  Rather interesting
>
> (cwd = /home/l4d2-1/left4dead2, where nemrun and srcupdatecheck scripts
> are)
>
> $ ./srcupdatecheck left4dead2/steam.inf
> Invalid steam.inf file.
>
> $ ./srcupdatecheck /home/l4d2-1/left4dead2/left4dead2/steam.inf
> Invalid steam.inf file.
>
> $ cat left4dead2/steam.inf
>
> // NetworkVersion is the version in the wire protcol between
> client<->server,
> // its not used for matchmaking, PatchVersion is used for that to ensure
> // we don't get cross connecting to different releases.  Only bump this if
> // you know an incompatible change has happened to the network protocol in
> // game and old demos will not work.
> NetworkVersion=2.0.4.2
> PatchVersion=2.0.5.3
> ProductName=left4dead2
> appID=550
>
> -
>
> compared to a tf2 steam.inf file (much simpler):
>
> PatchVersion=1.1.2.0
> ProductName=tf
> appID=440
>
>
> I *might* be able to fix this myself, if the problem is parsing...

So, I tried manually editing steam.inf a bit after reading the
srcupdatecheck code.  It looks like it expects to find the PatchVersion as
the first line of steam.inf, and may also expect to find ProductName as
2nd line, and appID as third line.  Once I changed the "test" steam.inf to
read this way:

---
PatchVersion=2.0.5.3
ProductName=left4dead2
appID=550
NetworkVersion=2.0.4.2
---

srcupdatecheck runs successfully!  Output below:

$ ./srcupdatecheck left4dead2/steam.inf
ProductName=left4dead2
appID=550
PatchVersion=2.0.5.3

[1] Requesting challenge
[1] Got challenge, sending registration
[1] - No response
[2] Requesting challenge
[2] - Timed out contacting server
[3] Requesting challenge
[3] Got challenge, sending registration
[3] - No response
[4] Requesting challenge
[4] - Timed out contacting server
[5] Requesting challenge
[5] Got challenge, sending registration
[5] - No response
Got three non-rejected queries, UP TO DATE!

So, time to brush the dust off my 2 brain cells and figure out how to
modify srcupdatecheck's python code to parse an L4D2-style steam.inf file
(since it seems unlikely that Valve is going to modify it to suit us... :)

If anybody cares to assist/suggest, feel free.  If I come up with
something that works I'll post it.

PharaohsPaw

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

Re: [hlds_linux] Anyone successfully using nemrun w/left4dead2?

[PharaohsPaw]

> Maybe I need to use setmaster* cmds in the running l4d2's to see which
> masters they are talking to and try modifying srcupdatecheck to one or
> more of those masters instead.  It's just a guess but maybe L4D2 servers
> need to talk to different masters to do version checking queries.
>
> Any ideas, Nephyrin?

OK, just for shi*ts & giggles I tried running srcupdatecheck manually from
the command line.  Rather interesting

(cwd = /home/l4d2-1/left4dead2, where nemrun and srcupdatecheck scripts are)

$ ./srcupdatecheck left4dead2/steam.inf
Invalid steam.inf file.

$ ./srcupdatecheck /home/l4d2-1/left4dead2/left4dead2/steam.inf
Invalid steam.inf file.

$ cat left4dead2/steam.inf

// NetworkVersion is the version in the wire protcol between client<->server,
// its not used for matchmaking, PatchVersion is used for that to ensure
// we don't get cross connecting to different releases.  Only bump this if
// you know an incompatible change has happened to the network protocol in
// game and old demos will not work.
NetworkVersion=2.0.4.2
PatchVersion=2.0.5.3
ProductName=left4dead2
appID=550

-

compared to a tf2 steam.inf file (much simpler):

PatchVersion=1.1.2.0
ProductName=tf
appID=440


I *might* be able to fix this myself, if the problem is parsing...



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

Re: [hlds_linux] Anyone successfully using nemrun w/left4dead2?

[PharaohsPaw]

> I just have a clean tf2 and clean l4d2 folder, which nemrun just updates
> for
> "fun" those instances do nothing. But it then uses the notify command.
> Which
> I use to send a sm_csay "Server is getting updated" and after a sleep of
> 10
> it does a quit. (there is bound to be a better way then updating a
> non-active game folder, but this was the easiest that came into mind)

Hi Eric,

Thanks for your reply.  I've been using nemrun in the past without much
trouble for CS:S and TF2.  And it still works for CS:S and TF2.  Was using
it to automate updating (and pausing/killing running servers) 2 CS:S and
2+ TF2 servers that were running off single trees of each game.

The problem I'm having is when trying to run nemrun for left4dead2.  So
far I've only even tested it against an updated "clean" tree (no plugins
etc.).  Just trying to get updatedaemon mode itself to work first, which
so far it doesn't for me.  I get the srcupdatecheck errors over and over.

I'd be inclined to think maybe I just have nemrun/srcupdatecheck in the
wrong directory, or am cd'ing into the wrong directory before running them
with my nemrun-updater script, or supplying incorrect steamdir/srvdir, but
I remember how apesh*t nemrun and srcds itself would go when I was first
setting up nemrun on CS:S/TF2 and didn't have the paths right - error
messages about no steam.inf (I think), segfaults/crashes, etc., and I've
not seen any of that with my testing of L4D2.  nemrun/srcupdatecheck
*seem* to be happy - ie, finding everything correctly.

Maybe I need to use setmaster* cmds in the running l4d2's to see which
masters they are talking to and try modifying srcupdatecheck to one or
more of those masters instead.  It's just a guess but maybe L4D2 servers
need to talk to different masters to do version checking queries.

Any ideas, Nephyrin?

Thanks,
PharaohsPaw


> -Original Message-
> From: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of
> PharaohsPaw
> Sent: woensdag 15 december 2010 18:14
> To: Half-Life dedicated Linux server mailing list
> Subject: Re: [hlds_linux] Anyone successfully using nemrun w/left4dead2?
>
>
>> [Wed Dec 15 06:27:38 EST 2010] :: !! srcupdatecheck failed. This
>> should not happen, server may not be up to date. (upa = 255).
>
> BTW I modded the error message output in nemrun to add (upa = $upa) so it
> would show the return value (I was trying to diagnose this in
> srcupdatecheck
> myself).
>
> I just completed a manual update with -verify_all by adding -retry to the
> steam command line.  Adding -retry seems to be the magic awesome sauce to
> get a -verify_all to complete without dumping the connection with an Error
> 104 (connection reset by peer).
>
> But anyway, even after a successful manual update with -verify_all, nemrun
> is still seeing same problems.
>
> PharaohsPaw
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
> !DSPAM:3,4d0921e623634935610036!
>
>
>


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

Re: [hlds_linux] Anyone successfully using nemrun w/left4dead2?

[PharaohsPaw]

> [Wed Dec 15 06:27:38 EST 2010] :: !! srcupdatecheck failed. This should
> not happen, server may not be up to date. (upa = 255).

BTW I modded the error message output in nemrun to add (upa = $upa) so it
would show the return value (I was trying to diagnose this in
srcupdatecheck myself).

I just completed a manual update with -verify_all by adding -retry to the
steam command line.  Adding -retry seems to be the magic awesome sauce to
get a -verify_all to complete without dumping the connection with an Error
104 (connection reset by peer).

But anyway, even after a successful manual update with -verify_all, nemrun
is still seeing same problems.

PharaohsPaw



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

[hlds_linux] Anyone successfully using nemrun w/left4dead2?

[PharaohsPaw]

Hi,

Have used nemrun successfully in the past for CS:S and TF2 servers, but I
can't seem to get it to work for left4dead2.  Does anybody else have
nemrun working for left4dead2?

I am getting errors from srcupdatecheck when trying to use nemrun in
updatedaemon mode on left4dead:

example output:

+ ./nemrun -nemlog nemrunlogs/updater_%Y%m%d%H%M%S.log -cleandownloads 10
-notifycmd /home/l4d2-test/update-email -autoupdate -steamdir
/home/l4d2-test/ -srvdir /home/l4d2-test/left4dead2/ -sharedscreens l4d2-1
-game left4dead2 -updatedaemon
[Wed Dec 15 06:27:38 EST 2010] :: Checking for updates
[Wed Dec 15 06:27:38 EST 2010] :: Running srcupdatecheck
[Wed Dec 15 06:27:38 EST 2010] :: !! srcupdatecheck failed. This should
not happen, server may not be up to date. (upa = 255).
[Wed Dec 15 06:27:38 EST 2010] :: Freeing update lock
[Wed Dec 15 06:27:38 EST 2010] :: Update check complete
[Wed Dec 15 06:27:38 EST 2010] :: Update daemon mode. Waiting a few
seconds and checking again!
[Wed Dec 15 06:27:40 EST 2010] :: Checking for updates
[Wed Dec 15 06:27:40 EST 2010] :: Running srcupdatecheck
[Wed Dec 15 06:27:41 EST 2010] :: !! srcupdatecheck failed. This should
not happen, server may not be up to date. (upa = 255).
[Wed Dec 15 06:27:41 EST 2010] :: Freeing update lock
[Wed Dec 15 06:27:41 EST 2010] :: Update check complete
[Wed Dec 15 06:27:41 EST 2010] :: Update daemon mode. Waiting a few
seconds and checking again!

steam binary is in l4d2-test user's home dir (/home/l4d2-test/steam), game
"tree" starts in /home/l4d2-test/left4dead2, and steam.inf is in
/home/l4d2-test/left4dead2/left4dead2.  I'm "pretty sure" I have the right
-srvdir and -steamdir specified, though I have also tried with both set to
"/home/l4d2-test/" and gotten the same results.  nemrun and srcupdatecheck
are located in /home/l4d2-test/left4dead2 along with srcds_linux and my
"launcher" script cd's into /home/l4d2-test/left4dead2 before starting
nemrun.  You can see the cmdline args I use in the above output.

I can't even figure out how we get a 255 return code out of
srcupdatecheck, especially since the only sys.exit() values I can find in
it are -1, 1, and 7.

Is this some weird master protocol thing like happened a few months ago
where srcupdatecheck would always return -1 (fixed by the last nemrun
update that only a change to srcupdatecheck was needed)?  Or maybe I'm
just doing something stupid?
nemrun still seems to work fine to update cs:s and tf2, just not l4d2. 
Haven't tried it with l4d1 yet but thinking of putting some of those back
up too.

thanks,
PharaohsPaw

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

Re: [hlds_linux] Nemrun v1.5.1 Released (bugfix... again)

[PharaohsPaw]

Thanks for the replies everyone.

> Tony is correct - optional updates are not detected at all by
> srcupdatecheck. The master server simply is not aware of them. To
> detect them would require A: A custom repository script abusing code
> deep inside hldsupdatetool (valve would not appreciate this), or B:
> Valve releasing some kind of XML feed or something with version
> information and optional update information.

> If you wish to manually trigger an update, however, when an optional
> update is available, you can delete /steam.inf - which will
> cause the update daemon to trigger immediately. If you're not using an
> update daemon, just delete steam.inf and reboot a server so its update
> check fires.
>

After reading more through srcupdatecheck it looked to me like it would
only exit with returncode 7 when a "server is out of date" message was
returned from a check.  There was one update a couple weeks ago (TF2 I
think) that got applied which I thought was optional from reading the
description, it's what made me wonder if nemrun was applying optional
updates, but it must have been something else.  I was using manual
deletion of the steam.inf file + -verify_all to force update checks (to
make sure I had things working correctly when an update came out) so it
was probably all my tinkering around that caused this non-required update
to be installed.

> As for warning people about an update before it happens, the script
> runs the -notifycommand synchronously - nemrun wont continue until it
> exits. So you can throw a warning in there followed by a "sleep 60".
> Of course with -updatefirst this isn't needed.


True, I was really only thinking it would be sort of nice to send a couple
alerts to the game (csay,hsay,etc.) a few seconds before sending the quit
command when update was complete, so ppl on the server would know that the
reason the server was going down/rebooting was because of an update,
rather than a crash or something.  Especially since the servers tend to
fill up pretty quick if yours are among the first updated and back online.

Thanks again,
PharaohsPaw

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

Re: [hlds_linux] Nemrun v1.5.1 Released (bugfix... again)

[PharaohsPaw]

>   Oh boy more spam.
>
> Its been brought to my attention that valve's master server ignores the
> requested port in server registration packets - instead using the source
> port of the packet to identify the server. This causes update daemons
> to register multiple fake servers on valve's list instead of just one -
> which isnt' the nicest thing for a script to be doing to valve's
> servers. So... fix'd.
>
> Get it here:
> http://nephyrin.net/tools/nemrun/1.5.1/
> (only the srcupdatecheck script has changed since 1.5)

Hi Nephyrin,

Thanks for your work with nemrun.  I've started using it in the last month
or so and it has been nice to use.

One question I've thought of after seeing it in action for a while and
looking at the srcupdatecheck script a bit -- and I get the impression
this may be more of an issue with challenge/responses -- but is there some
way to tell the difference between a mandatory update and an optional
update with the responses we can get from the valve master server
indicating an update is available?

The reason I'm wondering is, if there was a way to distinguish between
them, it might be neat to only have nemrun's updatedaemon only update the
server when it's a mandatory update.

I've also been working on adding a couple extra configurable screen stuff
commands so that when an update is detected, it will (for example) throw
an "exec update-pending-alert.cfg" into all the games running off of that
tree, with sm_say commands etc. to alert the players that are currently on
the server that an update is coming in - and another "exec blah.cfg" hook
for when the update is complete which execs right before sending the
'quit' to reboot the servers, so currently connected players know why the
server is about to go down and that they should reconnect.

Right now they only work for -updatefirst scenarios but I'm getting ready
to add similar options for when -updatefirst is not being used (as I am
probably going to stop using -updatefirst myself).

If thats something you think might be neat I'm glad to share what I have.

Cheers,
PharaohsPaw

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

Re: [hlds_linux] Counter-Strike: Source Beta Update Released

[PharaohsPaw]

> i'm 100% on this ride.
>
> This Lua crap on the client side is getting way out of hand.
>
> aim-bots
> wallhacks
> speedhacks
> as well as being able to crash the servers with it.
>
> Thanks for trying valve.
> I hope theres still a fix in the works and it's not just set aside to work
> on something else.

Indeed.  Aimbots in particular totally ruin the game for people that want
to play fair, and nothing will clear a server out faster, often before you
even get a chance as an admin to get rid of them.  We can detect or
prevent a lot of things with various scripts and plugins (and with varying
degrees of success), but there is still no real, effective aimbot
detection available for most Valve games.

It seems to me that a party (Valve) with true unfettered access to the
internals of the game engine on both client and server side, would be in
the best position to create ways to catch aimbots in use that minimize
load on the server.  If there was one thing I could ask for from the Valve
developers, this would be it.

However preventing clients from loading plugins, etc. should be a big help
and a good start, if it works.

cheers,
PharaohsPaw

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

Re: [hlds_linux] CS:S dedicated server (linux) update release coming?

[PharaohsPaw]

> Have you tried a manual update?  Maybe your auto update system is
> failing...

Yep, decided to "trick" nemrun into forcing a manual update with
verify_all.  Upon which, one of the CS:S servers running off this tree
became joinable and the other didn't.  Running 'status' in each of the
screened consoles, one reported version 1.0.0.47 and the other reported
1.0.0.48 (the one I was then able to get onto with my updated game
client).

Upon further inspection I found that the shutdown command ("quit") the
nemrun script had sent to the other server's screen when the update was
completed (the one that was still reporting 1.0.0.47 in status output) was
sent to the wrong "window", not the gameserver console, so it never
restarted itself after the update was complete.  The actual steam.inf file
had the correct 1.0.0.48 in it, and as soon as I typed "quit" in that
server's console, it reported the correct version when it came back up
(and I was able to join it).

Note to self (and maybe anybody else using nemrun): make sure if you are
going to use the updatedaemon mode and, that you either:

1) always leave the screen session running the gameserver instances on the
actual gameserver window (not some other window you might have opened in
that screen session).  Ie if you open an extra window to make a quick
config change or something, make sure you Ctrl-A-# back to the window the
gameserver is running in before you detach, or

2) (simpler) - just don't ever open any extra windows in the gameservers'
screen sessions, then you don't have to worry about which window the
"quit" command will be sent to. :)

nemrun is a really cool tool for linux gameservers.  I just have to pay
attention to what I'm doing and what it's doing. :)

cheers,
PharaohsPaw

PS:  Definitely, thank you to Valve for being better about the updates. 
The heads-up's, beta programs, etc. are all steps in the right direction
and as someone who has historically fussed among the loudest when an
update came out that broke something, I do feel obligated to say I do
appreciate the extra attention Valve is giving to getting good updates out
there and doing what you can to give us server ops a heads up.




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

[hlds_linux] CS:S dedicated server (linux) update release coming?

[PharaohsPaw]

Hello,

Per previous posts to list today from Valve, there is supposed to be a
dedicated server update to CS:S coming out sometime today?  We saw the TF2
update hit the servers but nothing so far for CS:S

Reason I'm asking is because our servers (and basically all the others out
there I've tried to connect to) haven't updated yet, servers are still
reporting version 1.0.0.47.  Our servers will immediately apply the update
as soon as valve releases it (thanks to nemrun) -- but the problem is our
clients have already updated.  ie, the clients are up to 1.0.0.48 now, and
none of the servers out there will let us join them (including our own)
because they aren't up to date with our clients.

So I guess what we really need is for that server update to come out...
and also to disable the keep our game updated option in the game library..
as this seems to be more trouble than good.

Can't understand why client update is available before the server update...




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

Re: [hlds_linux] Master servers gone foobar for CSS

[PharaohsPaw]

> --CLIP--
> setmaster remove 72.165.61.151:27014
> setmaster remove 69.28.140.246:27011
> setmaster add 72.165.61.151:27014
> setmaster add 69.28.140.246:27011
> Adding master at 72.165.61.151:27014
> Adding master at 69.28.140.246:27011
> A2C_PRINT from 69.28.140.246:27011 :
> Bad challenge.
> A2C_PRINT from 72.165.61.151:27014 :
> Bad challenge.
> --/CLIP--

yes thank you very much valve you have KILLED my CS:S servers.  I cannot
even setmaster add, immediately returns with bad challenge no matter what
masters I set manually.

Idiots.

I wonder if they can be bothered to fix this before they go home for the
weekend.

Guess what will happen to Valve if none of your customers have anywhere to
play...

>
> Can we get a fix?
>
> -ics
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
> !DSPAM:3,4b90b91e38224765610885!
>
>
>


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

Re: [hlds_linux] No challenge for your address

[PharaohsPaw]

> Hi,
>
> Would you mind sharing your config?

Trying again (quote from your reply):

> Call it over the top or whatever makes you feel better, but this is what I
> have added to my tf2/orangebox/tf/cfg/sourcemod/sc_jobs.cfg file on our
> TF2 servers:
>
> // force masters every 6 minutes since valve is criminally stupid
> sc_addjob ? ? ? ? 0 1 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 1 2 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 6 7 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 7 8 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 12 13 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 13 14 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 18 19 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 19 20 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 24 25 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 25 26 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 30 31 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 31 32 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 36 37 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 37 38 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 42 43 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 43 44 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 48 49 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
> sc_addjob ? ? ? ? 49 50 "setmaster remove 69.28.140.247:27011 ; wait ;
> setmaster add 69.28.140.247:27011"
> sc_addjob ? ? ? ? 54 55 "setmaster remove 72.165.61.151:27011 ; wait ;
> setmaster add 72.165.61.151:27011"
>
>
> Which to summarize, means that every 6 minutes, each gameserver will
> remove named master server from list of masters, wait 1 second, then add
> it back. A minute later, it does the same thing with a second server.


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

Re: [hlds_linux] No challenge for your address

[PharaohsPaw]

> Just adding another message to the list. My server has been getting
> spamming with this AC2 thing for a while now, and I don't show up on
> the master list now because of it. My server has always been Vanilla
> so I can't imagine it's any blacklisting problem.

Obviously Valve broke something in one of the last couple of recent
updates.  Imagine that

Hey Valve - when are you going to start up a dedicated server beta testing
program for the community so your OMGMUSTHAVE updates can be tested by
REAL SERVER OPERATORS before shoving them down everybody's throats and
blowing up servers by the thousands?

Most people running dedicated servers pay monthly rental fees and really
don't appreciate having a mandatory update render their server useless. 
Maybe if Valve had to pay the server bills for folks' servers that are
down because of megafail updates, Valve might take testing their updates a
little more seriously.

There is a sourcemod plugin named "Server Crontab" which can be used to
make your server execute various commands on a schedule.  This has proven
to be helpful with this latest Valve screwup.

Server Crontab Plugin
http://forums.alliedmods.net/showthread.php?p=523298

Call it over the top or whatever makes you feel better, but this is what I
have added to my tf2/orangebox/tf/cfg/sourcemod/sc_jobs.cfg file on our
TF2 servers:

// force masters every 6 minutes since valve is criminally stupid
sc_addjob ? ? ? ? 0 1 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 1 2 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 6 7 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 7 8 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 12 13 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 13 14 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 18 19 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 19 20 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 24 25 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 25 26 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 30 31 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 31 32 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 36 37 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 37 38 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 42 43 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 43 44 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 48 49 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"
sc_addjob ? ? ? ? 49 50 "setmaster remove 69.28.140.247:27011 ; wait ;
setmaster add 69.28.140.247:27011"
sc_addjob ? ? ? ? 54 55 "setmaster remove 72.165.61.151:27011 ; wait ;
setmaster add 72.165.61.151:27011"


Which to summarize, means that every 6 minutes, each gameserver will
remove named master server from list of masters, wait 1 second, then add
it back. A minute later, it does the same thing with a second server.

You may have acquired 2 totally different masters from a server startup. 
Don't worry about it.  After several minutes of (re)starting your server
those 2 (unless they happen to be one of the ones you define in your
sc_jobs.cfg) are going to be tits-up anyway and not helping you be listed
in the server browser (or getting you players), and having 4 masters
doesn't seem to be a problem.  At least you'll have 2 that ARE listing you
and bringing you players.

Clearly this is a problem where registering with a master (ANY master)
from a linux dedicated TF2 server only lasts somewhere around 6-10 minutes
before it forgets who you are and de-lists you.  By forcing a remove/add
with any working master every on a regular interval, you stay listed.

Map changes, as far as our testing has shown, do not affect the list of
masters your server currently has.

Try this.  It works.  Until Valve can put out an update that works.  I
won't be holding my breath.

PharaohsPaw



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