No, currently Boost.Log does not support process forking (i.e. fork call in UNIX systems). There are several
        issues with process forking, for instance:
      
- 
            File sinks do not attempt to reopen log files or synchronize access to
            files between parent and child processes. The resulting output may be
            garbled.
          
- 
            File collectors do not expect several processes attempting to collect
            log files to the same target directory. This may result in spurious failures
            at log file rotation.
          
- 
            The current_process_id
            attribute value will not update in the child process.
          
- 
            In multithreaded applications, one can generally not guarantee that a
            thread is not executing some Boost.Log code while an other thread forks.
            Some Boost.Log resources may be left irreversibly locked or broken in
            the forked process. This reservation is not specific to Boost.Log, other
            libraries and even the application itself are susceptible to this problem.
          
        There may be other issues as well. It seems unlikely that support for forking
        will be added to Boost.Log any time soon.
      
| ![[Note]](../../../../../../doc/src/images/note.png) | Note | 
| 
          This does not preclude the fork+execsequence from working. As long as
          the forked process doesn't try to use any of Boost.Log code, the process
          should be able to callexecor a similar function to load and start another executable. |