Initialize asyncio event loop before using it

[alimirjamali]

Python 3.14 (in Fedora 43) throws RunetimeError if event loop is not initialized before using it.

Resolves: QubesOS/qubes-issues#10188

[codecov]

Codecov Report

❌ Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.66%. Comparing base (5140b97) to head (7e4a837).
⚠️ Report is 106 commits behind head on main.

Files with missing lines	Patch %	Lines
qubes/tools/qubesd.py	0.00%	2 Missing ⚠️
qubes/tools/qubesd_query.py	0.00%	2 Missing ⚠️
qubes/tools/qubes_create.py	0.00%	1 Missing ⚠️
qubes/vm/__init__.py	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #723      +/-   ##
==========================================
+ Coverage   70.55%   70.66%   +0.10%     
==========================================
  Files          61       61              
  Lines       13616    16766    +3150     
==========================================
+ Hits         9607    11847    +2240     
- Misses       4009     4919     +910     

Flag	Coverage Δ
unittests	70.66% <0.00%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marmarek]

During normal execution, at this point the loop surely is running already, so this change should not be necessary (or maybe it can be changed to get_running_loop()?).
What I'm not sure is there is a loop running in tests reaching this function, but this should be easy to find, and create the loop in those cases.

[alimirjamali]

Ok. I changed this one toget_running_loop.

[reneleonhardt]

Nice contribution! What's still needed for Python 3.14?

[alimirjamali]

Nice contribution! What's still needed for Python 3.14?

I am not certain. Some of the pending issues are tracked on the main Fedora 43 issue. Like this one.

[reneleonhardt]

Thank you!
So is there something missing to undraft and review this? 🙂

[alimirjamali]

Thank you! So is there something missing to undraft and review this? 🙂

Actually this is also ready for review. The only issue is lack of time. More information here.

[marmarek]

This PR is for dom0, and there are no plans to change Python version in R4.3 dom0 (it will stay at 3.13). This PR may be useful only for the future (R4.4 and beyond).

[reneleonhardt]

What does may be useful mean?
It may not be needed for R4.3 but it modernizes docs, tools, tests and vm while still working on 3.13 (Fedora 41 and 42) and allowing CI to prepare in time for the next Fedora ❤️

[marmarek]

Yes, but at this time "main" branch is open only for changes that are necessary for R4.3.

[reneleonhardt]

I couldn't find this information in the README, only the master branch is being mentioned there.
Maybe you want to make the documentation clearer or introduce a v4.4 integration branch for future features.

[marmarek]

See https://doc.qubes-os.org/en/latest/developer/releases/version-scheme.html#release-schedule
Anyway, this is not the place for such discussion.

[marmarek]

PipelineRetry

[marmarek]

openQArun MACHINE=64bit

[marmarek]

With this PR, qubesd fails to start:

Feb 05 11:38:10.823025 dom0 qubesd[22337]: Traceback (most recent call last):
Feb 05 11:38:10.824614 dom0 qubesd[22337]:   File "/usr/bin/qubesd", line 5, in <module>
Feb 05 11:38:10.824614 dom0 qubesd[22337]:     sys.exit(main())
Feb 05 11:38:10.824614 dom0 qubesd[22337]:              ~~~~^^
Feb 05 11:38:10.824614 dom0 qubesd[22337]:   File "/usr/lib/python3.13/site-packages/qubes/tools/qubesd.py", line 48, in main
Feb 05 11:38:10.824614 dom0 qubesd[22337]:     args = parser.parse_args(args)
Feb 05 11:38:10.824614 dom0 qubesd[22337]:   File "/usr/lib/python3.13/site-packages/qubes/tools/__init__.py", line 425, in parse_args
Feb 05 11:38:10.824614 dom0 qubesd[22337]:     namespace.app = qubes.Qubes(
Feb 05 11:38:10.824614 dom0 qubesd[22337]:                     ~~~~~~~~~~~^
Feb 05 11:38:10.824614 dom0 qubesd[22337]:         namespace.app, offline_mode=namespace.offline_mode
Feb 05 11:38:10.824614 dom0 qubesd[22337]:         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Feb 05 11:38:10.824614 dom0 qubesd[22337]:     )
Feb 05 11:38:10.824614 dom0 qubesd[22337]:     ^
Feb 05 11:38:10.824920 dom0 qubesd[22337]:   File "/usr/lib/python3.13/site-packages/qubes/app.py", line 1040, in __init__
Feb 05 11:38:10.824920 dom0 qubesd[22337]:     self.load(lock=lock)
Feb 05 11:38:10.824920 dom0 qubesd[22337]:     ~~~~~~~~~^^^^^^^^^^^
Feb 05 11:38:10.824920 dom0 qubesd[22337]:   File "/usr/lib/python3.13/site-packages/qubes/app.py", line 1134, in load
Feb 05 11:38:10.824920 dom0 qubesd[22337]:     vm = cls(self, node)
Feb 05 11:38:10.824920 dom0 qubesd[22337]:   File "/usr/lib/python3.13/site-packages/qubes/vm/adminvm.py", line 103, in __init__
Feb 05 11:38:10.824920 dom0 qubesd[22337]:     self.start_qdb_watch()
Feb 05 11:38:10.824920 dom0 qubesd[22337]:     ~~~~~~~~~~~~~~~~~~~~^^
Feb 05 11:38:10.824920 dom0 qubesd[22337]:   File "/usr/lib/python3.13/site-packages/qubes/vm/__init__.py", line 617, in start_qdb_watch
Feb 05 11:38:10.824920 dom0 qubesd[22337]:     loop = asyncio.get_running_loop()
Feb 05 11:38:10.824920 dom0 qubesd[22337]: RuntimeError: no running event loop

:(

[reneleonhardt]

Seems to be the only place where a new loop hasn't been initialized yet:

loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)

Those breaking changes are surely not making it easier to use asyncio 😄