Fix panicking after starting UDP server due to closed "halt" channel#595
Merged
josecelano merged 2 commits intotorrust:developfrom Jan 11, 2024
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #595 +/- ##
===========================================
- Coverage 80.64% 80.57% -0.08%
===========================================
Files 117 117
Lines 7831 7854 +23
===========================================
+ Hits 6315 6328 +13
- Misses 1516 1526 +10 ☔ View full report in Codecov by Sentry. |
Added targets to all services especially when they start: [HTTP Tracker], [UDP Tracker], etc. ``` Loading default configuration file: `./share/default/config/tracker.development.sqlite3.toml` ... 2024-01-11T17:12:11.134816964+00:00 [torrust_tracker::bootstrap::logging][INFO] logging initialized. 2024-01-11T17:12:11.135473883+00:00 [UDP Tracker][INFO] Starting on: udp://0.0.0.0:6969 2024-01-11T17:12:11.135494422+00:00 [UDP Tracker][INFO] Started on: udp://0.0.0.0:6969 2024-01-11T17:12:11.135503672+00:00 [torrust_tracker::bootstrap::jobs][INFO] TLS not enabled 2024-01-11T17:12:11.135587738+00:00 [HTTP Tracker][INFO] Starting on: http://0.0.0.0:7070 2024-01-11T17:12:11.135612497+00:00 [HTTP Tracker][INFO] Started on: http://0.0.0.0:7070 2024-01-11T17:12:11.135619586+00:00 [torrust_tracker::bootstrap::jobs][INFO] TLS not enabled 2024-01-11T17:12:11.135675454+00:00 [API][INFO] Starting on http://127.0.0.1:1212 2024-01-11T17:12:11.135688443+00:00 [API][INFO] Started on http://127.0.0.1:1212 2024-01-11T17:12:11.135701143+00:00 [Health Check API][INFO] Starting on: http://127.0.0.1:1313 2024-01-11T17:12:11.135718012+00:00 [Health Check API][INFO] Started on: http://127.0.0.1:1313 ```
Member
Author
|
ACK 5fd0c84 |
This was referenced Jan 12, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relates to: #594
Context
We use a oneshot channel between the main app that launches the UDP server and the running UDP server. It could be used to send the "halt" message to the UDP server. When the app starts the server this server waits for that signal.
That code is not working because when the server starts waiting the channel is closed. That does not affect the server that is still running. And currently, we are not using that signal in production (only for test environments).
Details
The "halt" channel is immediately closed after starting the UDP tracker. So the app panics with:
The UDP is started but it's not possible to shut it down gracefully.
I've added a lot of debug lines in this PR:
The function panicking is:
When the thread starts waiting for the signal it receives the error "channel closed".
I fixed a similar problem for the Tracker API and the HTTP Tracker:
Apparently the problem was the sender in the channel was dropped (I don't know why, it looks like a compiler optimization).
In the end, I think the problem was we were not waiting for the right spawned task. I've reorganized the code but the change that fixed the problem is:
We needed to wait for the launcher to finish because in this case, the launcher is not the thread that runs the final server. So we were only waiting until the launcher was "launched" but not for the final task running the UDP server. That is the reason why the channel was closed prematurely.
I have also normalized the log output:
I'm using targets for some reasons: