-
Notifications
You must be signed in to change notification settings - Fork 443
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
20 seconds is not always enough to start Core #4678
Comments
Hmm.. this seems like a symptom of a deeper problem. The trivial fix would be to just increase the timeout. However, the deeper problem would be that we do too much disk I/O before startup. We should investigate the amount of disk I/O we perform before starting up. @synctext Maybe we can turn this into a longer term student project? |
Typically opening Python console and pasting a bunch of |
I suggest postponing fixing this for 7.5, when we will refactor the core startup system and Libtorrent Wrapper. |
Seems too low on science for a student project.. |
I moved the trivial solution, which we can easily fix, to #4680. We can get back to this issue (lazy loading dependencies) in the https://github.com/Tribler/tribler/milestone/31 milestone. |
Related to #4953 |
We already increased this timeout to 60 seconds. We also noticed that errors related to this traceback are usually because the core failed to start (e.g., due to an |
60 seconds may be not enough either. When system is significantly swapped to HDD, it may take around 5 minutes to thrash through those files. So it may fail to start twice because of 60-second timeout, then start successfully on the third attempt (with startup taking about 30 seconds). As a minimum, the timeout should be configurable in settings. As a maximum, Core should report some startup progress (such as number of Python modules imported) startup not timing out if starting up is progressing (although slow), only when it is actually stuck. Also when startup is taking a long time, it may ask for additional user confirmation before taking any action (like with "Forced shutdown" button). |
Tribler version/branch+revision:
7.3.0-beta6 + patches
Operating system and version:
Linux Debian Buster running on slow-ish laptop without SSD storage.
Steps to reproduce the behavior:
./tribler.sh
Expected behavior:
Eventually it starts like usual
Actual behavior:
GUI gets tired of waiting for core and bails out. Subsequent attempt to start Tribler works, as caches are hot.
Relevant log file output:
Here is startup log. The log looks like usual, except of the exception.
The text was updated successfully, but these errors were encountered: