> 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 > <ve...@tinylittlerobots.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_**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.000000 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.000000 >>> 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<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
