Re: [hlds_linux] [hlds] Optional TF2 update released
Hi Eric, I need some clarification on the usage of tf_workshop_map_sync. Are we supposed to put tf_workshop_map_sync lines in our server.cfg files? I ask because I'm NOT doing this and I've noticed some oddities: 1. The first time I changelevel to a workshop map, I see this in my server console: [TF Workshop] Preparing map ID 454118349 [TF Workshop] Map is not tracked, adding (as usual, I'm using cp_glassworks as a test) 2. This also appears to effect the results of the new FindMap function using for fuzzy matching. Running FindMap on workshop/454118349: - Results in workshop/454118349 if the map has not yet been played. - Results in workshop/cp_glassworks_rc6.ugc454118349 if the map has been played. - Results in workshop/cp_glassworks_rc6.ugc454118349 if tf_workshop_map_sync 454118349 has been run this session whether or not the map has been played. This concerns me as I am attempting to use FindMap to determine the "friendly" name of a map. In fact, I've already written the code to add this to the SourceMod MapChooser (although it still needs testing). 3. I have tf_workshop_map_sync 454118349 in a file I am execing from the command line, but that appears to execute too early as the map isn't being tracked. On 6/17/2015 4:45 PM, Eric Smith wrote: We've released an optional update for TF2. The notes for the update are below. The new version number is 2836387. -Eric - - Fixed an issue causing dedicated servers to occasionally hang on shutdown - Hammer tools: Fixed vbsp -onlyents and -onlyprops compiles failing - Updated localization files - Updated the Maps Workshop Beta - Fixed an issue causing clients or servers installed in long path names to be unable to load workshop maps - Fixed an issue causing clients to occasionally be unable to launch a listen server using a workshop map via the 'map' command - Fixed an issue causing the initial map load on dedicated servers to fail if the map is a workshop map - Fixed dedicated servers requiring a reboot to properly handle updated workshop maps if the map name changed ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] Optional TF2 update released
Thanks, that seems to have fixed the restart/quit issues! 2015-06-17 22:45 GMT+02:00 Eric Smith : > We've released an optional update for TF2. The notes for the update are > below. The new version number is 2836387. > > -Eric > > - > > - Fixed an issue causing dedicated servers to occasionally hang on shutdown > - Hammer tools: Fixed vbsp -onlyents and -onlyprops compiles failing > - Updated localization files > - Updated the Maps Workshop Beta > - Fixed an issue causing clients or servers installed in long path > names to be unable to load workshop maps > - Fixed an issue causing clients to occasionally be unable to > launch a listen server using a workshop map via the 'map' command > - Fixed an issue causing the initial map load on dedicated servers > to fail if the map is a workshop map > - Fixed dedicated servers requiring a reboot to properly handle > updated workshop maps if the map name changed > > ___ > 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
[hlds_linux] Optional TF2 update released
We've released an optional update for TF2. The notes for the update are below. The new version number is 2836387. -Eric - - Fixed an issue causing dedicated servers to occasionally hang on shutdown - Hammer tools: Fixed vbsp -onlyents and -onlyprops compiles failing - Updated localization files - Updated the Maps Workshop Beta - Fixed an issue causing clients or servers installed in long path names to be unable to load workshop maps - Fixed an issue causing clients to occasionally be unable to launch a listen server using a workshop map via the 'map' command - Fixed an issue causing the initial map load on dedicated servers to fail if the map is a workshop map - Fixed dedicated servers requiring a reboot to properly handle updated workshop maps if the map name changed ___ 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] Crash/hang on quit
Our CS:GO server have been a problem now for some time and now its not playable anymore as it crash on connection and restarts on game-port+1. I hope it will be fixed soon ! Peter Sweden On 2015-06-15 22:05, Erik-jan Riemers wrote: Would be nice if a valve person could say something about this, having to restart a ton every day. (killall srcds_linux) is the quickest, since they will restart after that, assuming you don't have other stuff about. 2015-06-15 21:45 GMT+02:00 pilger : Having this here as well. And it only happens after some quits... I'm not sure why and when. _pilger On 14 June 2015 at 08:38, Nicolas Seyer wrote: on the same system I have one server that stops but not the other. So I wouldn't think it is due to a library or the system itself On Sun, Jun 14, 2015 at 1:25 PM, Ilya Larin wrote: After the one of previous updates happened the same: i bet it now requires some more libraries in Linux system On 14 Jun 2015 14:23, "Martin V" wrote: Gaben for life <3 14 cze 2015 13:16 "Erik-jan Riemers" napisał(a): Of about 30 servers, a hand full did restart.. but the majority crashes. Consider being lucky ;p 2015-06-14 13:10 GMT+02:00 Martin V : Funny thing is that i dont have that problem. My server has about 100 plugin and I have no problem with exit, quit and restart commands 14 cze 2015 12:57 "Yun Huang Yong" napisał(a): "quit" and "exit" both used to exit cleanly prior to the update 3 days ago. We've been restarting our servers every night for ~2.5 years by simply sending an RCON quit. Hopefully this means it's a relatively easy change to revert/fix. On 14/06/2015 8:48 PM, Erik-jan Riemers wrote: And i thought it was just me, but indeed all my servers pretty much hang/crash. Tried a dozen things cannot get it to work normally again. Also booted up a micro instance on amazon, installed it fresh on ubuntu 14.04 with no extra's and also crashes. I restart the servers at night every day, but now they all just hang. (on multiple different servers) 2015-06-14 12:04 GMT+02:00 Jesse Molina : srcds_linux did this for years between something like 2009 and 2012. That's just a guess, I don't exactly remember the time frame. You should not expect srcds_linux to quit like it should. It is not a very well behaved bit of software. On 6/14/15 1:15, Yun Huang Yong wrote: Since the most recent update it seems that the server crashes (and hangs) on quit. This is on a stock (no MetaMod, no SourceMod) server: quit L 06/14/2015 - 18:12:07: server_message: "quit" L 06/14/2015 - 18:12:07: Log file closed. L 06/14/2015 - 18:12:07: server_message: "restart" /home/buildbot/buildslave/steam_rel_client_linux/build/src/tier1/../tier1/fileio.cpp (3997) : Assertion Failed: CFileWriterThread: pending file writer content_log.txt Assert( Assertion Failed: CFileWriterThread: pending file writer content_log.txt ):/home/buildbot/buildslave/steam_rel_client_linux/build/src/tier1/../tier1/fileio.cpp:3997 Not sure if I'm reading this right but it appears that the log file is closed, then something is issuing a "restart" but with the log file already closed the server then crashes into a hung state. The process never exits as it appears to then get stuck somewhere in the minidump: assert_20150614181208_15.dmp[17942]: Uploading dump (out-of-process) /tmp/dumps/assert_20150614181208_15.dmp Bad thread local/home/buildbot/buildslave/steam_rel_client_linux/build/src/tier0/threadtools.cpp (1416) : Assertion Failed: Thread synchronization object is unuseable Bad thread localassert_20150614181208_15.dmp[17942]: Finished uploading minidump (out-of-process): success = yes assert_20150614181208_15.dmp[17942]: response: CrashID=bp-166286bb-fd3c-46a7-b567-94dbe2150614 assert_20150614181208_15.dmp[17942]: file ''/tmp/dumps/assert_20150614181208_15.dmp'', upload yes: ''CrashID=bp-166286bb-fd3c-46a7-b567-94dbe2150614'' Apparently successful but process still never exits. Anyone else get this behaviour? It makes it awkward to exit/restart the server gracefully - I pretty much have to kill the process. cheers, yun ___ 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 __
