#88 -D option: "do not daemonize", -F option: "do not fork"

[Anatoly Pidruchny]

This is an improved patch 1689998. The issue with the original patch was that sometimes the grand-children of the main openser process stayed alive when the main openser process and its children terminated. The improvement is that now the main openser process creates a new process group even when "do not daemonize" option is used. This will allow the main openser process to send signals to the whole process group and that means that grandchildren will also receive signals from the main process and will also terminate with the main openser process and its children. The original description of the patch follows.

This patch is to allow to run OpenSER in "no-daemon" mode. We need to do this to run OpenSER under daemontools. There is a -D option already that means "Do not fork into daemon mode". But the problem with this option is that it really means more then just "Do not fork into daemon mode". It really means do not fork at all, i.e. do not create any child OpenSER processes. The patch below adds a variable no_daemon in main.c, makes -D option only change the no_daemon variable and makes the variable no_daemon only control whether OpenSER daemonizes itself or not. Another option, option -F, is added as the replacement of the old -D option. The -F option sets both no_daemon and dont_fork variables, so that it means exactly the same as -D option meant before.

Anatoly Pidruchny
NewCross Technologies
email: apidruchny@newxt.com

[Anatoly Pidruchny]

Patch for the main.c file.

[Bogdan-Andrei Iancu]

Logged In: YES
user_id=1275325
Originator: NO

Hi Anatoly,

looks good- I will start working on integrating it.

Regards,
Bogdan

[Henning Westerholt]

Logged In: YES
user_id=337916
Originator: NO

Hi Anatoly,

thanks for the patch, i ported it to current trunk, add a missing definition for the getopt function and applied it. Please reopen this patch or open a new bug report if you encounter any issues.

Cheers,

Henning

[Alex Hermann]

The patch+followup patch changes the semantics of the 'fork' option. Documentation states the default is 'yes'. But explicitly setting the option to 'yes' in the script has different behavior than not specifying it at all.
This makes the fork option a tristate rather than a boolean. This or the documentation should be fixed (where I prefer the behavior to be fixed, as it more intuitive).

current behavior:
fork=no -> daemon, not forked
fork=no + -D option -> foreground, not forked
fork=yes -> daemon, forked
fork=yes + -D option -> daemon, forked ===> -D is ignored !!!
fork not mentioned + -D option -> foreground, forked