Crash with existing file path in `log_directory` (Version: 2.1.1)

mounikakun commented 3 months ago

Issue Description

If an existing file path is added in "log_directory" of Clio config and start running Clio then Clio is throwing an exception and then crashing.

Steps to Reproduce

enable "log_directory" in Clio config with the path of an existing file

Expected Result

Throw an exception and stop running Clio

Actual Result

Throw an exception and then Clio is crashing

Environment

Reproducible in linux and Mac irrespective of Clio version.

Supporting Files

2024-04-05 08:50:02.560962 (util/log/Logger.h:265) [0x00000001fb4c3ac0] General:FTL Exit on exception: boost::filesystem::create_directories: File exists [system:17]: "/file/path/clio_log", "/file/path/clio_log"

2024-04-05 08:50:02.563254 (util/log/Logger.h:265) [0x00000001fb4c3ac0] General:FTL Exit on terminate. Backtrace:
 0# util::(anonymous namespace)::terminationHandler() in /path/of/clio/build/clio_server

 1# 0x000000019376D0F4 in /usr/lib/libc++abi.dylib
 2# 0x00000001937705F8 in /usr/lib/libc++abi.dylib
 3# boost::log::v2s_mt_posix::aux::lazy_singleton<boost::log::v2s_mt_posix::core::implementation, boost::shared_ptr<boost::log::v2s_mt_posix::core>>::get() in /path/of/clio/build/clio_server
 4# util::Logger::Pump::~Pump() in /path/of/clio/build/clio_server
 5# std::__1::vector<std::__1::thread, std::__1::allocator<std::__1::thread>>::~vector[abi:v160006]() in /path/of/clio/build/clio_server
2024-04-05 08:50:02.596899 (util/log/Logger.h:265) [0x00000001fb4c3ac0] General:FTL Exit on terminate. Can't get backtrace.
libc++abi: terminate_handler unexpectedly threw an exception

mounikakun commented 3 months ago

Verified the case for file path with Permission issue but Clio handled and threw an exception. 2024-04-05 08:35:16.689733 (util/log/Logger.hpp:346) [0x00000001fb4c3ac0] General:FTL Exit on exception: boost::filesystem::create_directories: Permission denied [system:13]: "/var/log/clio/clio.log", "/var/log/clio"

Please verify the above case too before closing the issue.

godexsoft commented 2 months ago

This is not a crash - the same happens on any other misconfiguration. Clio detects it, logs and exits cleanly. To me this looks like the correct/expected behaviour. Let us know if you disagree and what would be a good way to handle this. Thanks

legleux commented 2 months ago

If the error is legitimately Permission denied, it probably is the correct behavior. If you mess with rippled's paths as root (or any non-rippled user) you'll get a similar issue.

The ownership of the directories will depend on which user initially ran clio_server of course.

godexsoft commented 2 months ago

@legleux yes but there is slightly more to it than i thought originally. We do treat the permission error correctly but then some other exception happens when shutting down the rest of Clio and that is what produces the trace. While the first part is expected, the second part is certainly not! But we also have other issues in the pipeline that meant to battle similar problems (at least #442 is related).

XRPLF / clio