search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
526 stars 46 forks source link

Clear up error messages #4532

Open GammaSQ opened 5 years ago

GammaSQ commented 5 years ago

Qubes OS version: 4.0

A lot of commands fail with exceptions instead of clearly understood error messages. I guess this is common among all qvm-commands, I simply didn't test them all for every error-case. So here are just three examples:

qvm-run [VM] [CMD]
[Ctrl+C]
Traceback: [python-error-message...]
KeyboardInterrupt

Especially confusing: running command in any VM and interrupting doesn't change the running command in the VM. (so e.g. firefox will continue running)
But interrupting a command run in a dispVM (qvm-run --dispvm -- firefox + Ctrl+C) will kill the dispVM. (killing at the wrong time will keep the commandline red.)

qvm-pci d [VM] [VM:nonexisting device]
Got empty response from qubesdb. See journalctl in dom0 for details.
qvm-copy [already copied file to same VM]
A file named [filename] already exists in QubesIncoming dir
(zenity:13320): Gtk-WARNING ** : Theme parsing error: [... several lines of similar Gtk-warnings]

This one might be xfce-specific.

esote commented 5 years ago

From your first example: I agree that SIGINT should have better handling (looks like it isn't hard to do in Python). There aren't many cases were it would be helpful unless you need to debug. Maybe we should only include the stack trace with -v?

For the other two, I don't think those are too bad, and certainly not uncommon for commands on Unix-like systems. The first tells you to check the logs, and journalctl is sufficiently verbose. The Gtk-WARNING is (unfortunately) common for things that use gkt (not XFCE-specific). For example, run evince from command line and you'll see lots of those too.

GammaSQ commented 5 years ago

The first tells you to check the logs, and journalctl is sufficiently verbose.

What I don't see is why I have to check there at all? Sanity checking these commands should be easy. In this specific case, I imagine qubesdb is queried with VM and device-ID? Then an empty response could be translated to the user as: "Device [device-ID] does not exist in [VM]!"

marmarek commented 5 years ago

Especially confusing: running command in any VM and interrupting doesn't change the running command in the VM. (so e.g. firefox will continue running)

Right now qrexec protocol does not support "interrupt" signal of any kind, which is intentional in most cases. qrexec is meant as a transport layer between domains potentially with different trust levels. Interrupting a service in wrong time may have serious implications, including security issues. qubes.VMShell service, especially when called from dom0, is somehow special case here, because

  1. most shell command are expecting to be interrupted with SIGINT/Ctrl+C if necessary
  2. this service already gives the ultimate control over its target, so nothing worse can happen

Maybe the way forward would be a per-service configuration if given service call can be interrupted - by default enabled only for qubes.VMShell. But this is not a simple change, involve protocol change etc.

Branched to #4580

GammaSQ commented 5 years ago

Just for the record, I'm not sure quitting the command running in the VM is the best way to go. But the current error-message leaves the impression something went wrong which, as far as I can tell, isn't the case.

ninavizz commented 5 years ago

Bigger picture, a content-audit of all user-facing messages with recommended edits based on plain language and user-centric best practices, should happen. Not sure if an Issue has already been created for this, but flagging here.

andrewdavidwong commented 5 years ago

Bigger picture, a content-audit of all user-facing messages with recommended edits based on plain language and user-centric best practices, should happen. Not sure if an Issue has already been created for this, but flagging here.

I agree, @ninavizz, and I'm not aware of an existing issue for this. Please feel free to create one.

ninavizz commented 3 years ago

Updated 2018 milestone from 4.1 to ongoing as there's no linked PRs (unless @marmarek's 2018 PR fixed the specific nit this issue was created to correct?)

andrewdavidwong commented 3 years ago

Updated 2018 milestone from 4.1 to ongoing as there's no linked PRs (unless @marmarek's 2018 PR fixed the specific nit this issue was created to correct?)

Good thought to change the milestone from 4.1, but it should be "TBD," not "Ongoing." "Ongoing" is for things that are actually ongoing and are not (and will not) be implemented and released with any particular Qubes OS release. For example, a lot of documentation issues are on the "Ongoing" milestone because they are not release-specific. On the other hand, "TBD" means that it has yet to be determined to which milestone this will be assigned, but it must eventually be assigned to one (if it ever gets done), because it will be implemented for some specific release.

(Edit: Just updated the descriptions on the milestones to better capture this.)