View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000055 | LDMud 3.3 | Portability | public | 2004-04-27 22:25 | 2009-05-27 06:03 |
| Reporter | lynx | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000055: ldmud.conf + the ability to restart itself using exec(3) | ||||
| Description | It has been a fifteen year old tradition to start MUDs in shell scripts, but now some of us are looking into using the ldmud as a regular unix background daemon commodity. thank god we now have --pidfile, this brings us closer. what we need now is standard behaviour: restart on -1 and shutdown on SIGTERM if i'm not mistaken.. for the ldmud to learn the art of restart it needs to exec itself using the man 3 exec functions. you know how that works. and it needs to either copy itself all the arguments from the command line, or simply learn to accept all command line flags from an ldmud.conf file. wouldn't that be useful also for gdb runs? i never figured how to pass arguments to the patient with gdb... a simple solution that parses an /etc/ldmud.conf file as if it were the argv list would be perfectly sufficient. we can still think of improving the syntax in the next 15 years. thanx :) | ||||
| Additional Information | p.s. maybe the ldmud.conf as well as the key.pem and cert.pem should reside in the "server root" which to me is the directory *above* the mudlib (/opt/psycmuve instead of /opt/psycmuve/world) | ||||
| Tags | No tags attached. | ||||
|
|
Your are free to put the key.pem and cert.pem whereever you want. Regenbogen is started this way: $ ~mud/bin/parse -m/mud/mudlib --tls-key /mud/etc/key.pem --tls-cert /mud/etc/cert.pem ... |
|
|
yes yes a lot of this has been solved. this note is very old. so now we have --args to keep the command line flags in a file, we have flags to put the keys and certs wherever we want and we have pids to trigger a shutdown. the only thing that's missing is teaching ldmud to exec() itself so it doesn't need help from an external process to restart. that would allow us to have ldmud run on every other unix server as a background service without looking a bit funny... the .c and .o files are hard to grasp for the non-mudding audience already. |
|
|
I support this idea both for the config file and the restart. Especially for muds which reboot on a daily/weekly base, a mud-internal cronjob could just run this job. |
|
|
I just want to note, that to exec itself is not the same as a 'real' restart. exec() just overlays the current process image with a new one. There are a number of attributes (e.g. signals, resource usages, file descriptors) the 'new' process inherits from the 'old' one (see 'man execve'). While that is not necessarily a problem, one might have to check the driver initialization. And I don't know if there may arise problems if the old process is in a 'weird' state that requires a restart and the driver uses exec to restart. |
|
|
Any other comments or someone volounteering for having a look at the driver initialization and possible other implications? |
|
|
Hmmm.. thinking about it.. the /etc/init.d integration doesn't expect a true restart functionality anyway. It stops and starts stuff. So the extra service our wrapper scripts provide is to handle crashes rather than restarts. Even if we add this exec() behaviour, would LDMUD be able to crash gently and restart itself? Otherwise we'll just have to hope that crashes are a thing of the past... wooha. MUD admins will keep their shell wrappers anyhow, and us lpc commodity people should be fine being able to shutdown/restart ldmud from an init script. |
|
|
LDMud _may_ be able to gracefully exec itself in case of a call to fatal() - but there is no guarantee. In case of the process being killed or terminated by a signal (SIGKILL, SIGBUS, SIGSEGV), this will not work. Concerning init+wrapper scripts: We have a shell script (if you don't fancy shell scripts, write a small wrapper in C *g*) which starts the driver, waits until it dies and restarts. This wrapper is started+daemonized by the start-stop-daemon in /etc/init.d/mud. The alternative to the wrapper is to run a periodic cronjob which checks for the running driver and calls '/etc/init.d/mud start' if not. And I concur: I don't see, that you can offer reliable service without some external program monitoring the driver, even if it can exec itself. It would just be a matter of convenience for some non-existing restart() efun. ;-) |
|
|
I suggest to close this as WONTFIX as well. (The config file issue was long fixed by the --args <filename> argument.) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-04-27 22:25 | lynx | New Issue | |
| 2004-07-13 04:11 | Gawain | Note Added: 0000089 | |
| 2005-12-13 12:06 | lynx | Note Added: 0000459 | |
| 2008-01-25 17:07 | Coogan | Note Added: 0000586 | |
| 2008-01-26 05:49 | zesstra | Note Added: 0000588 | |
| 2009-03-03 15:00 | zesstra | Note Added: 0000966 | |
| 2009-03-03 15:00 | zesstra | Status | new => feedback |
| 2009-05-22 01:37 | lynx | Note Added: 0001127 | |
| 2009-05-22 03:53 | zesstra | Note Added: 0001137 | |
| 2009-05-25 08:11 | zesstra | Note Added: 0001154 | |
| 2009-05-27 06:03 | zesstra | Status | feedback => closed |
| 2009-05-27 06:03 | zesstra | Resolution | open => won't fix |
