-
Notifications
You must be signed in to change notification settings - Fork 79
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
MultipleHandler's using nohup to run binary #103
Comments
Hello. With |
Thanks for your reply. Did you test with FIM 0.4.6? I will perform some tests and come back with the steps to reproduce it. Apart from that thanks for let me know about tokio-signal I didn't know it. |
I did not run FIM, as it has so much code that it's not trivial to pinpoint the issue. If you can come up with a simpler example I could debug why the issue is happening. |
After updating my dependencies, I too am encountering this issue when using nohup. This didn't used to be an issue and we've always used nohup with this code. My case seems very simple, the set_handler call is the very first thing that happens. Nonetheless, my attempts at a standalone test case have all run fine so far. |
The |
I'm reverting the implementation for #98 and moving it to |
Please update to 3.4.0 to get the overwriting functionality back. I'd also suggest checking whether you really need the |
Thanks @Detegr. Will review my requirements. |
Hello!
I have detected a weird result using your crate. I am programming a File monitor tool in Rust just for context.
Suddenly, my CI tests failed to give this stack trace:
After a lot of research, I detected that the ctrlc crate is detecting multiple handlers to something like background execution. The FIM process is called with
&
in some of the failed tests but from my shell, the error doesn't appear at all. The only way to reproduce this issue is by using thenohup
command to start up FIM. Then the error is always present.In this link, you have the failing code and the solution applied now:
Failing code: https://github.com/Achiefs/fim/blob/90b39d5e53b3c2952fc4ad09e14f57ea3ad8764a/src/monitor.rs#L152-L164
Partial solution: https://github.com/Achiefs/fim/blob/9455ce7a6d6fee4f91a5a6a6021cfca58c7595b2/src/monitor.rs#L152-L167
Apart from that, I want to know if there is some solution, workaround or a way to manage the
SIGINT
signal when nohup is used. I think this is related tonohup
attaching the FIM process to theinit
process (That probably handlesSIGINT
). But I am not an expert in this field.It also fails on Github actions using
&
more info here: https://docs.github.com/en/actions/managing-workflow-runs/canceling-a-workflow#steps-github-takes-to-cancel-a-workflow-runThe text was updated successfully, but these errors were encountered: