Updating files in place is definitely asking for problems. Keep in mind that the use of VPK files add a new wrinkle. If a VPK is updated and the files inside shift their offset, there's a good chance that if you try to load the file after updating, it won't just a valid but perhaps mismatched file, which is what would happen before. It will essentially load random bytes.
If there is no map change, and it doesn't need to actually load any files, then there's a decent chance that will work. I would expect that any map change that happens after the an in-place update begins has a high chance of crashing. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nikooo777 Sent: Thursday, April 18, 2013 4:45 PM To: [email protected] Subject: Re: [hlds_linux] Symlinked Server Setup No idea, my servers never crashed when doing an update. I guess it's because of linux loading the binaries into memory. It once happened that i deleted the whole installation when running it and i can swear after all data was deleted the server was still up on hlsw (had some troubles joining it tho). Sent from Samsung Mobile -------- Original message -------- From: Russell Smith <[email protected]> Date: To: Half-Life dedicated Linux server mailing list <[email protected]> Subject: Re: [hlds_linux] Symlinked Server Setup How would this not cause a crash? You're overwriting the binaries that are currently running on your symlinked servers. On 18.04.2013 15:30, Nikooo777 wrote: > That's just a waste of space. Use one base installation and when > needed update it. Your game won't crash. If you have multiple > gameservers then symlink the binaries etc and for each installation > install mm and sm. > > > Sent from Samsung Mobile > > -------- Original message -------- > From: Bjorn Wielens <[email protected]> > Date: > To: Half-Life dedicated Linux server mailing list > <[email protected]> > Subject: Re: [hlds_linux] Symlinked Server Setup > > What I plan to do is keep two copies of the full srcds install. > > First one of them is updated. Then all the servers are shut down, and > the new files are copied over to the second full install. The servers > are symlinked to the second install. Best of both worlds ;) > > > > > ________________________________ > From: Russell Smith <[email protected]> > To: Half-Life dedicated Linux server mailing list > <[email protected]> > Sent: Thursday, April 18, 2013 1:41:33 PM > Subject: Re: [hlds_linux] Symlinked Server Setup > > > To piggy back on this thread, how are you guys handling srcds updates? > The only disadvantage I can see with symlinking is you then cannot > launch with -autoupdate on each of your instances, but you can't > update the master copy either while the children are running. > > Are you guys then just manually shutting down all servers to update > the master copy every update? > > On 4/18/2013 4:34 AM, Bjorn Wielens wrote: >> Thanks all for the insight. I've also been looking at the forked >> server thread on alliedmods where it's mentioned that MM can be >> symlinked, but sourcemod should not be. >> >> I've got a pretty good idea now what I want to do after hearing how >> other folks manage it. We use CPGS to manage the servers so it won't >> be necessary to actually start/stop/restart them from the script - >> what I'm looking to write is just some scripts for rapid updating of >> metamod, sourcemod, and tf2, along with a rapid way to deploy a new >> install with our standard plugin and config loadout. >> >> Cheers! >> >> >> >> ________________________________ >> From: Erik-jan Riemers <[email protected]> >> To: Half-Life dedicated Linux server mailing list >><[email protected]> >> Sent: Thursday, April 18, 2013 4:54:58 AM >> Subject: Re: [hlds_linux] Symlinked Server Setup >> >> >> Well i am no isp, so I don’t have to keep that in mind. Also we use >> updater.smx which removes any symbolic links if a new update is out >> on the plugins. Looks nice the gui Ulrich, might come in handy for >> less scriptfull people. >> >> Only thing that was left, was there now an option to tell server >> owners which custom content it is allowed to load? I think not right? >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of >> Ulrich Block >> Sent: donderdag 18 april 2013 9:45 >> To: Half-Life dedicated Linux server mailing list >> Subject: Re: [hlds_linux] Symlinked Server Setup >> >> I am also using a symlink setup. My system has a masteruser which >> owns the masterfiles/server. This user is within the same group as >> the users that own the actual gameservers. Linking serverplugins >> decreases the needed adminsitration. Update mms/sm once and all your >> servers can make use of updated binaries. >> >> >> When I install a server or serverplugin like mms/sm I work in two >> passes. >> >> 1. pass is to copy files from master a user needs to edit >>(incomplete extension list und wrote down from my memory): >> cd masterfolder/ >> find -type f -name "*.cfg" -o -name "*.ini" -o -name "*.smx" | >>while read file; do >> if [ ! -d targetserver/`basename $file` ]; then mkdir -p >>targetserver/`basename $file`; fi >> cp $file targetserver/$file >> done >> >> 2. pass symlinks the rest recusive. Previously copied files won´t get >> overwritten: >> cp -sr /absolutepath/to/masterserver/* /absolutepath/to/targetserver/ >> >> >> If you only have a few servers and do not mind using an interface, >> you might be interested in easy-wi.com. It makes use of symlinks and >> has a free version. >> >> >> Am 18.04.2013 08:54, schrieb Erik-jan Riemers: >>> This is my script what i have so far, i want to improve more on it >>> when >> i >>> have the time like making an easy way to upgrade metamod/sourcemod >>> and update plugins too. >>> >>> http://pastebin.com/TzULi9M4 it keeps the configs of all servers in >>> a .servers file which should make it easy to create and remove new >>> servers to get default servers up and running quickly. Tested with >>> tf2 and css. >>> >>> This is my own worklog to keep our other admins in the loop, >>> http://wiki.lethal-zone.eu/pages/viewpage.action?pageId=7798805 >>> feel >> free >>> to copy it over if it has any value for you. But some of them asked >>> what has changed, so made a diagram of it. If you see something >>> wrong or have >> a >>> better way, I am all ears. >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> Bjorn Wielens >>> Sent: donderdag 18 april 2013 2:39 >>> To: Half-Life dedicated Linux server mailing list >>> Subject: [hlds_linux] Symlinked Server Setup >>> >>> In light of the upcoming tf2 server switch to steampipe, I'm working >>> on >> a >>> new server setup which is symlinked, and I have a question I hope >> someone >>> here can answer. Skip down two paragraphs to go straight to it, or >>> read >> on >>> for background on what I'm trying to do. >>> >>> Background: What I ultimately want to do is have several tf2 server >>> directories (e.g. server1, server2, server3) which all have symlinks >>> to the files in a single "master" directory to which updates are >> downloaded. >>> These servers (1, 2 and 3) can then be customized as to their >>> mapcycles/configs/etc, but don't use much additional disk space for >>> each new install. >>> >>> My question pertains to addons, specifically SM/MM). I recall >>> reading about some of this, but can't seem to hit the right >>> combination of keywords to find it again via google. >>> >>> Here goes - Symlinking Sourcemod and Metamod: Can components of >>> these (esp. plugins, configs) be symlinked or is it necessary to >>> have a unique copy for each server? >>> >>> >>> Also, is 232250 the final appid for tf2 steamcmd or will that become >>> 440 at the actual switchover? Sorry if that's been answered before. >>> >>> Thanks! >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list >>> archives, please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list >>> archives, >> please visit: >>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >>> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
