> 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
