If you've been running into issues with the server crashing, you might
find running the server under GDB useful for seeing where the server
crashed. Of course the only problem with this is when GDB stops running
the program, it just returns a command prompt and awaits your input,
instead of restarting the server.
This is the Bash script I'm using to start my DOD:S server right now:
#!/bin/bash
export LD_LIBRARY_PATH=".:bin:$LD_LIBRARY_PATH"
dtach -n ./terminal.dod1 -r winch taskset 0x0000000C -- gdb -q -batch -x
./gdbinit \
--args ./srcds_i686 -debug \
-game dod \
-pidfile ../pid.dod1 \
-tickrate 33 \
+ip 1.2.3.4 \
+hostname "Hostname" \
+map dod_donner \
+maxplayers 26 \
dtach mimicks screen's detach feature and taskset relegates gdb and
srcds to processors 2 and 3 (I'm running two processors with HT).
Anyway, the good parts are gdb's switches. "-q" starts it in "quiet"
mode, so it doesn't print anything except the prompt when you start it.
"-batch" removes the prompt entirely and instead executes a series of
commands specified in the file chosen by the "-x" switch. In my gdbinit
file, I have the following:
set logging on
while 1
run
bt
end
The first makes gdb log all of its own output to "gdb.txt" in the
current working directory. "run" starts the program of course, and when
the program finishes running, it runs "bt" (short for "backtrace"). If
the server segfaults, this will print a backtrace of where it crashed.
Or more simply, it'll print the function in which the server crashed,
and the list of functions that were called to get to that point.
After the program quits, it restarts it again. This is definitely useful
for keeping the server up, but it can be annoying if you're trying to
forcibly quit the server. If that's the case, you should probably just
run "quit" once and then hit ^C two times to exit gdb.
Anyway, hopefully someone will find this information useful. I'm really
only running gdb on my production server at the moment because the
source server crashes without it due to some sort of incompatibility
with my kernel, but it's still useful for getting real crash information
in real situations for reporting bugs.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
