Kill a paused qube before system shutdown #616
Conversation
|
This doesn't look right. If a qube was paused, it was likely done for a reason, it shouldn't execute anything without explicit user action. Maybe kill paused qubes on shutdown instead? |
This sounds more dangerous. What if the qube had open applications with proper auto-save on shutdown mechanism. Killing qube might lead to serious data-loss. Having said that, killing disposables might be a legitimate option. |
|
Ideally, we'd ask the user, but I don't think we have any way to do that. The autosave is one scenario, but if user wanted to interact with such a qube, why it was paused? Another scenario could be some misbehaving qube paused to limit damage - unpausing it would be very wrong here. |
|
So properly killing it would be the way. I will look into p.s.: And documentation should be updated that paused domain will be killed on shutdown. |
alimirjamali
force-pushed
the
Issue-8580
branch
from
a059b61
to
a2ad22f
Compare
|
See what qvm-kill does. BTW, I think killing should be only during system shutdown. Normal qvm-shutdown should not automatically change to killing on a paused qube but maybe show an error or some other message? |
supplements: QubesOS/qubes-issues#8580 main patch: QubesOS/qubes-core-admin#616
|
@marmarek It is done. |
Ops. Just saw this. I will work on it. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #616 +/- ##
==========================================
- Coverage 69.33% 69.31% -0.03%
==========================================
Files 58 58
Lines 11946 11950 +4
==========================================
Hits 8283 8283
- Misses 3663 3667 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
alimirjamali
force-pushed
the
Issue-8580
branch
from
a2ad22f
to
8d29d4d
Compare
supplements: QubesOS/qubes-issues#8580 main patch: QubesOS/qubes-core-admin#616
alimirjamali
changed the title
alimirjamali
force-pushed
the
Issue-8580
branch
2 times, most recently
from
37c9ee9
to
2ff9968
Compare
|
@marmarek I believe it is done properly. Trying to shutdown a paused qube will raise proper error (instead of doing nothing). Please let me know if you are OK with it, so I could proceed with updating unittests. This is the screenshot of the error: |
alimirjamali
force-pushed
the
Issue-8580
branch
from
2ff9968
to
b2b290f
Compare
|
Reason for amendment: Making Pylint happy(er) |
Yes, this looks reasonable |
|
It appears that CI/CD is broken at the moment. I do not have access to PipelineRetry |
alimirjamali
force-pushed
the
Issue-8580
branch
from
b2b290f
to
aa7fd22
Compare
|
OK. Codecov is advising on the necessary unittests. I have a crude idea on the required unittest. Might be wrong |
alimirjamali
force-pushed
the
Issue-8580
branch
2 times, most recently
from
059171e
to
be197f0
Compare
alimirjamali
force-pushed
the
Issue-8580
branch
from
be197f0
to
8344dad
Compare
|
@marmarek It appears that none of the basic integration unittests are executed. I am having trouble to find the proper unittest to update for this. |
|
Integration tests are not running in gitlab-ci, they are running only in openqa, see https://www.qubes-os.org/doc/automated-tests/ |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024100113-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024091704-4.3&flavor=update
Failed tests16 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/112766#dependencies 199 fixed
Unstable tests
|
fixes: QubesOS/qubes-issues#8580