Search / View

[hika]

I think this topic could be the place for any WQ3 server admins

I have a suggestion / wish about how can a wq3ded behave about system's signals :
Is it possible to handle the signal 1 (e.g SIGHUP) in order to reload the config files and parse the pk3 files in search paths, one more time ?
That way, we can avoid any server restarts when it comes to a config file change or some new pk3 files adds.
So, in case, WQ3 servers are always full (which I hope in the futur ), we can avoid kicking all players when the server admin just wants to change something.

If needed, this is a part where I could help.
I can start from the original Q3 source files.
If patchs will be available, then I think it is more appropriate to incorporate these in the standalone version, first.
Then, why not for the other quake3 forks : icculus, FreeBSD's quake3 and cleanq3 ... etc

Oh ... and I forget about Windows ... I don't think it will know anything about signals
So, if anyone have some other alternatives, just let us know

[ReD NeCKersoN]

Both of our coders are on vacation so it'll be a week or two before they can discuss these things with you.

[hika]

Both of our coders are on vacation so it'll be a week or two before they can discuss these things with you.

Yeah, I know that torhu and sig11 are having fun with holidays .
They will see that topic when the time comes.
BTW, I will be off too, for a few days. I'm actually on vacation (for only 2 weeks)

[ReD NeCKersoN]

When do you leave? Dammit, no more updated test servers for awhile I guess. And we had something very special in store for the testers this Saturday. Trust me, it's a BIG surprise.

[hika]

When do you leave?

I will be gone, next week (my last week), probably Wednesday.
So, we can expect BIG surprise, this week end

[Caffeine]

Works for me.

[hika]

When analysing a bit the Quake 3 source files, I have found a way to handle the system's signal.
I have also found how we can reload the config file given by the following command line (In this case, it is server.cfg)

Code: Select all

q3ded +set fs_game westernq3 +set dedicated 1 +exec server.cfg

However, I have lost my time , since the server admin can easily do the same by executing the following command in the console

Code: Select all

\rcon exec server.cfg

By doing this, the server just reinterpret the config file, and btw, reload the cvars and start the default map (that trigger a map change).
I noticed that a map change trigger another pk3 parse in the search paths (see console log on each map change).
That way, newly put pk3 files will be loaded.

Anyway, I can provide a small patch to handle the SIGHUP signal and do the same as this \rcon exec <myconfig.cfg>, if anyone (playing with Linux or *BSD) are interested ...

[sig11]

I think this is generally a good idea.

And in the end, you may not even have wasted your time ... the server configuration file can be called anything, not just server.cfg (In fact, mine are called differently for the different servers). If it is possible to remember the exec command and re-execute it after receiving a SIGHUP, this could be very useful.

And yes, a map_restart or a map change does at least a partial reset of the search path etc.

But either way, I'm interested in your patch ! Maybe we can do something with it.

[hika]

If it is possible to remember the exec command and re-execute it after receiving a SIGHUP, this could be very useful.

But either way, I'm interested in your patch ! Maybe we can do something with it.

Here is the following patch, made from the original quake3-1.32b-source.zip source file, to handle the SIGHUP signal :

Code: Select all

--- ./code/unix/linux_signals.c.orig    Tue Aug 16 01:10:07 2005
+++ ./code/unix/linux_signals.c Tue Aug 15 21:38:23 2006
@@ -40,6 +40,28 @
   }
 
   signalcaught = qtrue;
+ 
+#ifdef DEDICATED
+  // Only for dedicated server
+  switch(sig)
+  {
+    case SIGHUP:
+      printf("Received signal %d, reloading...\n", sig);
+     
+      // Add possible startup commands, given on command line,
+      // in the command text buffer
+      if ( Com_AddStartupCommands() )
+      {
+        // Then, execute them
+        Cbuf_Execute();
+      }
+      // Signal has been caught
+      signalcaught = qfalse;
+      return;
+      break;
+  }
+#endif
+ 
   printf("Received signal %d, exiting...\n", sig);
 #ifndef DEDICATED
   GLimp_Shutdown(); // bk010104 - shouldn't this be CL_Shutdown

(The endlines are in \r\n style ! Not \n UNIX style !)

To comment the code, I know that Com_AddStartupCommands() gets the Q3 commands given from command line ("+exec server.cfg" for example), and add them to some text buffer.
Then Cbuf_Execute() execute all commands stored in the text buffer, and remove them from the buffer.
That way, following the example, the "exec server.cfg" will be re-executed, and, of course, a map change will be done by launching the default map.

[sig11]

I've applied the patch against my development version and tested it a bit. Looks very good !
And simply re-executing the command line seems to be indeed the best and simplest way ! Thanks, hika ! It will most likely make it into the next SA version.

Maybe I'll add anothe signal handler (for e.g. USR1/USR2) to restart the current map and to change to the next map - or maybe not ... or maybe I'll give the game a possibility to store its PID to a file (just like any decent UNIX server ...).

[hika]

Glad that I could help
I hope this feature will be very helpful !

Maybe I'll add anothe signal handler (for e.g. USR1/USR2) to restart the current map and to change to the next map - or maybe not ... or maybe I'll give the game a possibility to store its PID to a file (just like any decent UNIX server ...).

About the PID file, if implementation is planned, what about a cvar to store its path ?
And then, something like

Code: Select all

kill -1 `cat /path/to/pidfile`

will be certainly more interesting than a

Code: Select all

pkill -1 wqded

or

Code: Select all

killall -1 wqded

especially if there are multiple wqded instance.

If needed, I could help about these tiny things, as I guess there are not very important for the stand alone project (and wq3 players)
Just some comfort for server admins.

[sig11]

About the PID file, if implementation is planned, what about a cvar to store its path ?

Yes.

And then, something like

Code: Select all

kill -1 `cat /path/to/pidfile`

will be certainly more interesting than a

Code: Select all

pkill -1 wqded

or

Code: Select all

killall -1 wqded

especially if there are multiple wqded instance.

Exactly.

If needed, I could help about these tiny things, as I guess there are not very important for the stand alone project (and wq3 players)
Just some comfort for server admins.

Actually, lately the code changes to the SA are all of that sort of nature ... all the important stuff is there like smooth integration of engine and game and some important fixes like the ATI skybox fix.
My current list is more or less:
- see if ioq3 or similar projects found any serious bugs
- Fix a demo file-name case mismatch between load and save (only affecting Unix)
- Allow for UID change and chrooting the server (half way there ... and I porbably will have to make it w/o cvars )
- The PID/signal handling stuff
(Note: the bug you found about the dynamite throwing close to the wall: I don't know yet, if it's the engine or the game - maybe somebody else knows already)

But if you want to do something there, go ahead ! In unix/unix_main.c in main(), the cvars are parsed when doing Com_Init(cmdline). So, sometime after that, possibly in the #ifdef section a few lines further down might be a good place to dispatch to save the PID.

[hika]

I have made some patches to handle the PID save in a file.
A cvar named sv_pidfile can be set to change the file path.
When stopping the dedicated server, PID file unlink is also handled.
I have add a signal handler for SIGINT, typically when we kill the dedicated server by CTRL+C

Anyway, here are the file patches made from quake3-1.32b-source.zip
http://wq3.bsdmon.com/stuff/patch-code-unix-linux_signals.c
http://wq3.bsdmon.com/stuff/patch-code-unix-unix_main.c

However, I guess some fixes like handling permission and PID file path are needed if chroot and setuid are planned.
Either way, just take what you need, as I don't think code will be let as is

[sig11]

Cool !

Too bad, I was rather busy the last few days ... and now the URL does not really answer ... I somehow remember you talking about your setup but I forgot ... If you want to, you can just mail me, to either s1g11@westernquake3.net (that's three 1's in s1g11) or sig11@bootblock.de
in the meantime, I will keep trying to download.

[hika]

... and now the URL does not really answer ...

Yeah, too bad, 'cause my home server has just crashed the past few days.
Now, you should normally reach the URLs.