Boost.Log and creating daemons; `fork` disallowed?

Question

I need to add a command-line option to my application saying that it is to be run as a deamon.

However, I am also using boost logging library to keep logs of this application, and I found out that boost logging does not support forking.

This seems to prevent me from forking, and as such I cannot create a daemon.

Is it possible to bypass this problem, or;
can I create a daemon process without forking?

Why don't boost logging not support `fork`? Isn't there a way to work around this problem? After all all processes except `init` are the result of a `fork`. — skyking, Oct 09 '15 at 07:41
@skyking http://www.boost.org/doc/libs/1_57_0/libs/log/doc/html/log/rationale/fork_support.html Though I would guess you can still daemonize if you initialize the logging after you've fork'ed. — nos, Oct 09 '15 at 07:46
Is forking still a problem when only the child process is allowed to continue living and logging? Some of the described problems relates to multiple processes logging simultanueosly - in the double-fork scenario for a daemon this won't happen. If that's still a problem is there a way to postpone initialization of boost logging until after the second fork? — skyking, Oct 09 '15 at 07:48
@skyking it will be a problem if you have started to log from the parent processes, but you are safe if you start logging in the child process (never in the parent). See my answer for info. — Filip Roséen - refp, Oct 09 '15 at 07:54
@FilipRoséen-refp That's why I asked if it's possible to postpone initialization of the boost logging until after the second fork. — skyking, Oct 09 '15 at 08:11

score 1 · Answer 1 · edited May 23 '17 at 11:59

The forks in a daemon play an important role for the daemon to work as expected as mentioned in the answers to this question.

If the only problems are due to multiple processes logging the fork should not be a problem since you don't have to log befor you have done the forks. Besides the parent processes of these forks are going to terminate anyway.

If termination of the parents are problematic, you could maybe postpone initialization of the boost logging until after the second fork.

If boost logging is always initialized before main the solution might need to be to make sure that the forks happen even before that, that is to manage to make the code run befor boost logging initialization - which will need a implementation specific solution.

For an implementation independent (other than posix support) solution for the worst case scenario is to use execl to make sure that the actual daemon doesn't fork, that you in effect use one program that does the daemonizing thing which don't use boost logging and one program that's the proper daemon program. If it's not a big problem with fork if you don't use the logging fascility (after the fork) you could even do this with one single executable and differ the behaviour from command line switches. In pseudo code:

int main() {
    parse_command_line();

    if( no_daemonize_flag() )
        run_daemon()
    else {
        daemonize();
        execl("/path/to/daemon", "/path/to/daemon", "--no-daemonize", ...other flags..., NULL);
    }
}

Boost.Log and creating daemons; `fork` disallowed?

1 Answers1