-- [ Picked text/plain from multipart/alternative ] We get both Kevin We reboot our servers every 24 hours at around 5am, and some of them won't go secure.
Later on we will reboot the ones that did not come up as VAC Secure, and they wil come up as VAC Secure. At some random time in the future before the usual 5am restart process, and not necessarily the same servers that did not go VAC Secure during the reboot process, will go VAC INSecure, without a server reboot or crash. I am watching our servers diligently at the moment and they refuse to now go VAC INSecure. If I left them for 6 hours (I don't want to do this) no doubts some will go VAC INSecure while I am not watching. On 1/20/06, Ian mu <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > Too true! I doubt there's be much to see anyway apart from the same > message > when it can't connect on startup though, at least thats "more" replicable > as > I seem to get that quite frequent. > > Like others, happy to help with any tracing/debugging if needed. > > > On 1/20/06, Whisper <[EMAIL PROTECTED]> wrote: > > > > -- > > [ Picked text/plain from multipart/alternative ] > > A watched VAC enabled server never goes insecure :( > > > > On 1/20/06, Ian mu <[EMAIL PROTECTED]> wrote: > > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Have this mainly on windows (pretty sure we've had it on linux as > well, > > > just > > > less css servers on it). > > > > > > Notice it more on a restart, server starts up, goes secure for a few > > secs, > > > then message unable to contact (steam/valve/auth servers whatever it > > is), > > > then goes secure 0. Normally on another restart its the same for me, > but > > > after a few variations in time on restart it ends up fine. It's > > different > > > servers each time and different boxes, so no specifics and I doubt > > config > > > etc. > > > > > > Maybe there's just too much traffic hitting certain boxes at certain > > times > > > and it times out or something? If there's a pool, can it try one > server, > > > if > > > no response try a different one or something ? Thats the way it feels > > > anyway. > > > > > > > > > On Fri, 20 Jan 2006 00:55:47, Dan Sorenson <[EMAIL PROTECTED]> wrote: > > > > > > > > At 09:06 PM 1/19/2006 -0500, Ray wrote: > > > > > > > > >Exactly my point, nothing is in the logs and the server isn't > crashed > > > so > > > > >their's no dump. The bottom line is it's impossible for us to help > > you > > > > fix > > > > >what's broken. > > > > > > > > Oh, it's not impossible. It's just difficult. There's > > probably > > > > a command-line flag you can set to put the server into dev mode and > > > > increase the debug level. Who knows? Perhaps there being nothing > in > > > > the logs is the clue that's needed -- something that should be > logged > > > > not being there is just as important as something being logged with > > > > an error. > > > > > > > > The other thought is that server startup only takes a few > > > > seconds, maybe a couple of megs worth of traffic to get registered > > > > and grab VAC. Fire up MS's Netmon or maybe Ethereal and do a packet > > > > capture and send that off. Alfred should be able to take that, > filter > > > > on his VAC servers, and see exactly what's going out and coming > back. > > > > I don't know Valve's network infrastructure, but chances are it's > all > > > > a switched network. Send Alfred a private e-mail with your server > IP > > > > and perhaps a schedule of when you'll restart and I bet Alfred will > > > > be able to get some logging enabled, perhaps mirror a server port > > > > and do his own packet capture. > > > > > > > > That's how I'd approach it, anyway. Alfred's a busy guy > > > > and I don't want to say he can or will do this, but it seems to me > > > > that this approach gives him something more solid to work with. > > > > > > > > - Dan > > > > > > > > * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] > > > > * Vikings? There ain't no vikings here. Just us honest farmers. > * > > > > * The town was burning, the villagers were dead. They didn't > need * > > > > * those sheep anyway. That's our story and we're sticking to it. > * > > > > > > > > > > > > _______________________________________________ > > > > To unsubscribe, edit your list preferences, or view the list > archives, > > > > please visit: > > > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > > > -- > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > -- > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
