next »

[Please Support Us!]

Please Support Us!

Please help keep (=WDG=) alive

• Server rules
• Forum rules
• Join us
  
• Clan members
• About the clan
• Server stats
• WDG YouTube Channel
• WDG Downloads
• IRC Webchat

Steam groups:

• WDG community
• WDG clan group
• WDG Battlelog Platoon

Our allies:

• [NuB] TF2 clan
• Velocity Gamers Hub
• Destination Gamer

GoG Links:

• Wix Discord
• Wix IRC channel

TF2 Links:

• Official TF2 Blog
• TF2 Steam Forum
• The Fort 2

October 2025

Mo	Tu	We	Th	Fr	Sa	Su
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31
	Birthdays
Uzz919 (29), FlowingEye (36), Karthus (35)
	Upcoming Events
Upcoming Birthdays: Uzz919 (29), FlowingEye (36), Karthus (35)

[claws]

You added more plugins after it was already crashing?

Do you have enough control on the host to add a stalled/hanging check and auto-restart it? Obviously that isn't a fix but maybe it'd help?

Assuming it isn't a problem with the host, I'd probably go to the set of 'approved' plugins and go from there.

[Jebus]

Was going to say I thought the problem had been around a lot longer than last set of server changes. The only thing I can think of is that it seems to crash when the map vote occurs in the last round of the map. Might be wrong though...

But if it is maybe there is some conflict where the server has already picked a map before the vote kicks in?

[Omnipotens]

Hey,

Have you ruled out a memory leak?

One of my CS servers used to hang (amongst other issues) on a particular build of linux we were running on the box at the time. After a certain amount of map uptime, where no players were present, issues would creep in until eventually the server would hang, but only after player activity had resumed. The code really didn't seem to like to linger on a particular map for hours with no activity.

Before we moved to a new build of linux which cleared things up (never did get to the bottom of the fix for the memory leak), the solution I came up with was to run a cron job to kill and restart the server in the dead of night.

[Junta]

Do you have enough control on the host to add a stalled/hanging check and auto-restart it? Obviously that isn't a fix but maybe it'd help?

There are batch files already for this purpose, but they ONLY restart after a termination of the server. If the server hangs, it doesnt actually terminate, hence no auto restart.

I still think we should revert to basic plugins from Allied Modders (i.e. SOurcemod official ones), then add back the others over time, assessing server stability.

There really is no other way to work it out, or we're just randomly tinkering without knowing what caused the problem

@ Omni: I found it an interesting co-incidence that when the server hangs, and I go onto the dedicated server box via remote desktop, the CPU utilisation is nearly 100% accross the 4 cores. The utilisation drops after a manual restart of the server... so I guess plugins maybe triggering this action.. maybe also worth considering a race condition between plugins.. of course, resetting the server also drops TF2's memory allocation too... so we can't ignore that either.

[claws]

I agree re the plugins John - what I was trying to say (badly) with the check is checking for high cpu/zombie process and restarting

[r007]

@John, Omni:
Not at all a coincidence. This problem is not unheard of across the internet, and I think I remember having read one account from someone who managed to get a backtrace that sourcemod gets stuck in a tight loop (hence all the cpu utilization) when this happens.

Therefore my suggestion of obtaining a process dump. AFAICS, alliedmodders has a Symbol Server up, which should allow determining where it goes wrong.
That's probably the next best thing (diagnostics-wise) to installing a full debug build of sourcemod on the server (VisualStudio Express should be enough to get that running, if desired...).

Poking around with the modules seems very "voodoo" to me, I'm more of a fan of the "brain surgeon" approach.

[Junta]

I personally would see adding debug tools to the server as a last resort. Brain surgeon it may be, but I prefer the "blunter approach" () of trialling base plugins first.

I don't really want to get into debugging Sourcemod and plugins written by 3rd parties , although I would admit stack trace / exception info would give a clue WHAT triggered the f*ck up.

When I get time, I'll review the server logs to see what ran prior to a freeze (action wise). We can correlate this to known crash times and see if there is a pattern.

First things first: Can someone post a *definite* date and time of a recent crash please?

[CruelCow]

Just add a script that restarts TF2 when CPU usage is too high, problem solved.