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 greaaaaat 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 >> <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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
