Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mounikakun opened this issue Apr 5, 2024 · 4 comments · May be fixed by #1857
Open

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

mounikakun opened this issue Apr 5, 2024 · 4 comments · May be fixed by #1857
Labels
bug Something isn't working
Milestone

Comments

@mounikakun
Copy link
Collaborator

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 mounikakun added the bug Something isn't working label Apr 5, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Clio Apr 5, 2024
@mounikakun
Copy link
Collaborator Author

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 godexsoft changed the title [Clio is crashing if an existing file path is added in the "log_directory" of Clio config] (Version: [Clio version]) Crash with existing file path in log_directory (Version: 2.1.1) Apr 6, 2024
@godexsoft
Copy link
Collaborator

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
Copy link
Collaborator

legleux commented Apr 8, 2024

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
Copy link
Collaborator

@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).

@godexsoft godexsoft added this to the 2.3 milestone Jun 17, 2024
@godexsoft godexsoft modified the milestones: 2.3, 2.4 Oct 21, 2024
@kuznetsss kuznetsss linked a pull request Jan 29, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: 📋 Backlog
Development

Successfully merging a pull request may close this issue.

3 participants