[PATCH] core-admin: QubesWatch: do not create multiple dom0 QubesDB connections

23 views
Skip to first unread message

HW42

unread,
Jul 17, 2016, 4:45:47 PM7/17/16
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

since commit 7e9c816b (included since qubes-core-dom0 3.2.5)
QubesWatch._register_watches() is called twice for dom0 [0]. This
uncovered that _register_watches() does not handle multiple calls for
dom0 correctly (see commit message for details). This leads to (at
least) two bugs in qubes-manager:

1) qubes-manager misses when a block device becomes available during
runtime of qubes-manager so no notification is shown and you cannot
attached it through the GUI.

2) qubes-manager misses the qrexec startup when a VM is started
externaly (e.g. qvm-start ...). Therefore it thinks qrexec does not
run and for example "Run Command in VM" hangs.

While debugging two things in QubesWatch.__init__ raised my attention:

1) Is _register_watches() intentionally called a second time in L711 for
dom0? (Might be a preparation for not Xen based libvirt backends)

2) L708 should be a 'continue', right?

HW42

[0]: It was already called twice before but _register_watches()
mishandled the libvirt_domain object for dom0, so effectively it was
only called once.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXi+40AAoJEOSsySeKZGgWkFMQAJAFkve3+td92o1sQS2p2kSU
qmF5Z3gP+316+/pPjwN8zGVjGlWT2bRLV/+PTGq+tXXIOAF4HmJYOFFj2tXYNDBk
siiM1bJqcIEWmKe45W2D5135rIo40/tVbBbQSerTsg7yFx1UzEimbTCQgQHOj6pj
hMW/StQoux4DBZNXC51vevZVGvfDmdE6Gjifyp5QWWkDAS0r+OSkAA0g5FVDrtSb
47S/9ZHmUT82i4OSYfHwkXDc+44ZcWMGBoYfRGnNKkwVri1Zltq/6z3lcbaNMtHV
ayE6m2fk0ouhISKKTZHb6QPp/LeMmQLiGygX2v51elFJhVkdC5sLyNf4Lp1uTIJG
ReidxAJejNEes3f+lfS+V2V+MkihKZ7mG6GaUgYrvkulHozm2wF4LOckdzm70CzV
eur8LEFc3QbOtJKQVq1WObTg/IAXreoou67sgoKeUKW9R4396qKTHGQJ2w0bPP2s
r+G773YPzclt/kQpCHEzkFOQNv0+253LSdOyvii2SNtFao49aMW+oBD7YaXSMvt8
btbBHosS5UJoucR3p7mD64xqf89miXBGNsS4lYJXnTfxW1dMcju+99gDXrrPHVc8
A5s8j5UCETq2pn8ttmZAJPpV1hkECzO5/FRYtzNlmxcxtlMtYp7mdBh7nYDv5dQu
tuntAp1/0/yieXkyVi6z
=BxBq
-----END PGP SIGNATURE-----
0001-QubesWatch-do-not-create-multiple-dom0-QubesDB-conne.patch
0001-QubesWatch-do-not-create-multiple-dom0-QubesDB-conne.patch.sig

HW42

unread,
Jul 17, 2016, 8:32:31 PM7/17/16
to qubes...@googlegroups.com, Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

HW42:
> Hi,
>
> since commit 7e9c816b (included since qubes-core-dom0 3.2.5)
> QubesWatch._register_watches() is called twice for dom0 [0]. This
> uncovered that _register_watches() does not handle multiple calls for
> dom0 correctly (see commit message for details). This leads to (at
> least) two bugs in qubes-manager:
>
> 1) qubes-manager misses when a block device becomes available during
> runtime of qubes-manager so no notification is shown and you cannot
> attached it through the GUI.
>
> 2) qubes-manager misses the qrexec startup when a VM is started
> externaly (e.g. qvm-start ...). Therefore it thinks qrexec does not
> run and for example "Run Command in VM" hangs.

This is seems to be #2178. I observed both hanging after trying to run a
command in a VM through the GUI as well as the "qrexec not running"
error message as described in the ticket.

> While debugging two things in QubesWatch.__init__ raised my attention:
>
> 1) Is _register_watches() intentionally called a second time in L711 for
> dom0? (Might be a preparation for not Xen based libvirt backends)
>
> 2) L708 should be a 'continue', right?
>
> HW42
>
> [0]: It was already called twice before but _register_watches()
> mishandled the libvirt_domain object for dom0, so effectively it was
> only called once.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXjCNeAAoJEOSsySeKZGgWKz0QAJuhsdvIgjHeVaU1frIHwINo
MLaiwHhHx4fHRgHcIn4eSIbc8qiBdR7ZwvVY7wdHc/pJdIPZB7cNU1U/2Hx5RBW4
/+YiOZuKqe8qOJBwjYm2mYJEHqgswe8LrYjp8ePaY3xTV0q3RqNxKShdDtm6Tomb
RV0AmlzWfnna1I7WrOjHa8nEMkcnBJVEStEXqBXpN2SteooJTuNdiEP5xNXfy6Ba
yvImDK4fZLjcTkmVpKnZP800bFtkpJ3FsmxsTgWTcwB8M5z5eG0jd745askHN7uS
1BMduwgjY4KX9BQotvuUEEmdu2LNgmy+96YbcT4nW3nl7FHDRH/2IIof9BsuQKdx
taAWhtC438Cx6ADpNK3a85NNpOemu+DvTYDqWW4sXjI+gZbtvvWrUYczoZs0Rx/C
4JgWZC5tIhLgViPd9dq2DcD7kS0XZFFJin9Jm50OGYrL0Z6hVkTXidRpI897GUS0
LU9WmuY1bKTj0xDQJ09DCMXiG/y/26BJs1K3geGRiAjfbQNDEOFYag462gCJI5eW
Ja8iCuAeJV+sesEqxhMBioGrKCQgbdoEZZtLI2Sc/qNY1T87pqizRF2AWUY5BF72
QA2HTt3s7Gkg2HD8rrxhr8JfsSMz//F7gdSTnth5s4c7xWundF8ndQ9BWG2yn1Pm
I956lUJhiPpmoLnAcaZG
=aug+
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki

unread,
Jul 18, 2016, 9:06:45 AM7/18/16
to HW42, qubes...@googlegroups.com, Patrick Schleizer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jul 18, 2016 at 12:31:00AM +0000, HW42 wrote:
> HW42:
> > Hi,
> >
> > since commit 7e9c816b (included since qubes-core-dom0 3.2.5)
> > QubesWatch._register_watches() is called twice for dom0 [0]. This
> > uncovered that _register_watches() does not handle multiple calls for
> > dom0 correctly (see commit message for details). This leads to (at
> > least) two bugs in qubes-manager:
> >
> > 1) qubes-manager misses when a block device becomes available during
> > runtime of qubes-manager so no notification is shown and you cannot
> > attached it through the GUI.
> >
> > 2) qubes-manager misses the qrexec startup when a VM is started
> > externaly (e.g. qvm-start ...). Therefore it thinks qrexec does not
> > run and for example "Run Command in VM" hangs.
>
> This is seems to be #2178. I observed both hanging after trying to run a
> command in a VM through the GUI as well as the "qrexec not running"
> error message as described in the ticket.

Yes, indeed, thanks!

> > While debugging two things in QubesWatch.__init__ raised my attention:
> >
> > 1) Is _register_watches() intentionally called a second time in L711 for
> > dom0? (Might be a preparation for not Xen based libvirt backends)

It depends on libvirt version. Earlier ones do not have domain object
dom0. And as you've said, other drivers in the future may also not list
it.

> > 2) L708 should be a 'continue', right?

Yes, or rather there should be "else:".

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXjNReAAoJENuP0xzK19csWZ4IAJCiTgRN1Ogh0mNQEnZMlhEC
0tj2u0JcNrbU56q8U5zEkmn3jmn6XWt5fW0oyJjsHlU9w69Mp1Idb6tUx216Ce9J
G7IkVaTgOv1d8t1tHaxgtcDDp6vSw0wBWfp9m+SYKL6gV3/ky0EypjPhMUhe/SGN
grTUtmOJ7c7S85Ty3uOesHwv7ZlUHdeAB3nQeVGwhYpBLg/wM0s6nPuX5j6/qtoq
6UiHdWxzUvwv/LY9ZiR+nDwwE+9mTwPuM+r19BDgZT/lhwadNM08M8n9C8pf3uSr
iFPe4FZdQQc5p9LVEzxfT9eLsvxTrN4i+67RnoItiYmXH9YF9FF1+f1pAYISqI0=
=DcY1
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages