As pointed out originally in SERVER-104691, boost::filesystem::exists can throw exceptions when its call to the stat or statx system call fails with an error that doesn't simply indicate non-existence. We do not catch exceptions that can be thrown by boost::filesystem::exists when we call it as part of opening log files.

One way this can go awry is that the server can crash during startup when we initialize the log file or the backtrace file. As an example repro, simply run mkdir ~/log && chmod 220 ~/log && mongod --logpath ~/log/mongod.log --logappend. boost::filesystem::exists will throw an exception because stat will fail with EACCES. The result is a backtrace, and this error message that doesn't help clarify the root cause of the issue:

"msg":"Threw exception","attr":{"type":"N5boost10filesystem16filesystem_errorE"}

We should either wrap the call to exists in a try block, handling exceptions appropriately, or call the non-exception-throwing variant by passing in a boost::system::error_code argument, which we can then interrogate for errors.