[Patch] daemonizing mangos and a few new args

[spermik]

Hi I have added the --daemonize option for mangos (under unix) - someone has asked for that on the forums. I have also added the -h and --help options which will print usage and exit. And at the and I have added --quiet option (for unix) which will redirect stdout and stderr to /dev/null to suppress all output from mangos (which can be useful when debugging it under gdb - it will not spam your gdb console, which you are probably sending to some file to see backtraces and etc.).

http://tabak.spermik.info/dev/mangos/daemon.patch

Best regards

Tabak

[VladimirMangos]

Maybe add in same time same options for realmd for completeness? Also i worry about demon(0,0) call. Possible #include require maybe?

Please anyone who test patch post what platform used test.

[freghar]

Maybe add in same time same options for realmd for completeness? Also i worry about demon(0,0) call. Possible #include require maybe?

Please anyone who test patch post what platform used test.

unistd.h

/* Put the program in the background, and dissociate from the controlling

terminal. If NOCHDIR is zero, do `chdir ("/")'. If NOCLOSE is zero,

redirects stdin, stdout, and stderr to /dev/null. */

extern int daemon (int __nochdir, int __noclose) __THROW __wur;

But I have some things to add:

* Why the hell removed author the CR (\\r) from windows help print? I really don't know if that is going to work well on win.

* About the --quiet parameter - perhaps I'm too old, but I'd still do it by closing all FDs (with a loop) or directly calling close on stdin and stderr (1,2) and then opening both on /dev/null. You don't need "nul" stream pointer this way (not to mention that I have NO idea why you're opening a FILE stream and converting it to file descriptor instead opening the file descriptor directly).

* I'm curious about the daemon(3) call. Even if the support for it is in GNU/Linux, *BSD and Mac, probably excluding Solaris, I'd still use fork + setsid + close 0,1,2 and open them on /dev/null (with check if such device exists!) + chdir ..., we could tune it to use for example vfork instead of fork when available, but whatever, daemon(3) will work too.

edit: Well .. to fetch something on point and get the "critic jerk" label off me, here's my old C daemonizer - http://paste2.org/p/157871 , I wrote it a while ago so no idea if it's left it in a functional state, but it should work. Maybe you can get some ideas from it.

[spermik]

unistd.h

But I have some things to add:

* Why the hell removed author the CR (\\r) from windows help print? I really don't know if that is going to work well on win.

* About the --quiet parameter - perhaps I'm too old, but I'd still do it by closing all FDs (with a loop) or directly calling close on stdin and stderr (1,2) and then opening both on /dev/null. You don't need "nul" stream pointer this way (not to mention that I have NO idea why you're opening a FILE stream and converting it to file descriptor instead opening the file descriptor directly).

* I'm curious about the daemon(3) call. Even if the support for it is in GNU/Linux, *BSD and Mac, probably excluding Solaris, I'd still use fork + setsid + close 0,1,2 and open them on /dev/null (with check if such device exists!) + chdir ..., we could tune it to use for example vfork instead of fork when available, but whatever, daemon(3) will work too.

edit: Well .. to fetch something on point and get the "critic jerk" label off me, here's my old C daemonizer - http://paste2.org/p/157871 , I wrote it a while ago so no idea if it's left it in a functional state, but it should work. Maybe you can get some ideas from it.

the unistd.h is included in Common.h so no need to include it again.

1. the CR is added automaticky, because stdout is text (not binary) stream. Btw the correct order is \\r\\n, not \\n\\r so even if you will keep that in source it will be in bad order.

2. the dup2 function does what we need. It closes the second parameter and copyes the first to that. But you are right, i should use directly open, not fopen and convert (I will correct it when I came home).

3. the daemon is not supported on all unix like systems (it is not standert possix function), but is supported on most newer BSDs and all Linux systems.

I will read your source and maybe correct and/or make it more multiplatform.