qvm-run fails silently with chromium

[ma...@lamarciana.com]

Hi,

I installed chromium browser in a debian-8 based standalone VM called 'work'. If I run, from dom0:

```
qvm-run work chromium
```

it outputs:

```
Running command on VM: 'work'...
```

but nothing happens. It is the same if I use shortcut desktop menu (which I guess executes the same command).

If, instead, I run `chromium` from within a terminal in 'work' it works fine.

I thought maybe it was a permissions problem with folder `~/.config/chromium`, but I granted everything to everybody just to check it and nothing changes.

I'm quite lost because, as there is nothing in dom0 stderr, I don't know how I could debug it.

I would be thankful for any help.

Thanks!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Is chromium the only program with which you experience this problem?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYm5DQAAoJENtN07w5UDAwqF8QAIAFoV8PSp3JseDUXT4OLemO
fmFtz79wNyUMmcj010XHpCg0mMb/QcKZh0gDZaQLqjHyH55YoIg+RfxV6Sntm1qL
MTmnNBlDjMfspViZ2y0F63LnIZA5VNiHVzY9DHQqv2sPn5mkECgB7YrpfO/viatd
8EUmynutXojfXYvIjVwoaIq+bV5NB7XkoVij48dDHMSUJEqwMj7NxdnKSv6bVa6w
jP01a67KHF84gaVgaiPvkxVhfuDOM5Euj8hR6aXZaUEHNVM4CmjKm1ZtZjVwm2Lv
3dlbylbPAlixr/GDYtGlQ8UyIfziSZ3oFLprwGPdeBAoY8nFI8RDzmvzyD1L/gr2
oR3yURw1pnD91fUo4zO5lQS0Ry37kejeCrCfdD8GgrrhB6QpUbwsuV9tChsSHB5G
T27JMg7YR+6fLI8UxqsQ028xXqolWb/fBcwnBR6pfSL3c/sXLjyog3fFKDmowEsz
FlPNt6rNSAQVprBU7RLrIt7g89wQfliSro4pUXbr1BcQz1hbxCMAd9C051fE6Bnu
buSW0sCD+FT8i/UN7FYue2M6qERXUkHBnTR7JeCDV6N+DkNLwAWMG57UryLenKm0
DD+cQ78OBmMfbbwo+aGeKPooX3xXxgb8Yarpwh2BmBgt3beD461GudkZ3I1YKCeU
IAw9S91T3yQnJGEJsm6H
=+KIj
-----END PGP SIGNATURE-----

[Unman]

I dont see this behaviour in a TemplateBased qube, or a standalone.
In both, the browser just opens.
That's with a standard Debian-8 template.

You can try running with '-p' option to see if any errors are being
thrown.

[haaber]

On 02/09/2017 03:31 AM, Unman wrote:
> On Wed, Feb 08, 2017 at 01:42:44PM -0800, Andrew David Wong wrote:
> On 2017-02-07 06:35, ma...@lamarciana.com wrote:
> >>> Hi,
> >>>
> >>> I installed chromium browser in a debian-8 based standalone VM
> called 'work'. If I run, from dom0:
> >>>
> >>> ```
> >>> qvm-run work chromium
> >>> ```
> >>>
> >>> it outputs:
> >>>
> >>> ```
> >>> Running command on VM: 'work'...
> >>> ```
> >>>
> >>> but nothing happens. It is the same if I use shortcut desktop menu
> (which I guess executes the same command).
> >>>
> >>> If, instead, I run `chromium` from within a terminal in 'work' it
> works fine.
> >>>
> >>> I thought maybe it was a permissions problem with folder
> `~/.config/chromium`, but I granted everything to everybody just to
> check it and nothing changes.
> >>>
> >>> I'm quite lost because, as there is nothing in dom0 stderr, I
> don't know how I could debug it.
> >>>
> >>> I would be thankful for any help.
> >>>
> >>> Thanks!
> >>>
>
> Is chromium the only program with which you experience this problem?
>

> > I dont see this behaviour in a TemplateBased qube, or a standalone. >
In both, the browser just opens. > That's with a standard Debian-8
template. > > You can try running with '-p' option to see if any errors
are being > thrown. >

Hello, did you run "Add more shortcuts" at least once (look which apps
are there)? I got very confused by this point in another, maybe related
situation: when changing the templateVM you *must* do so, since symbolic
links to all apps are different in fedora and debian, for example. All
the best, Bernhard

[ma...@lamarciana.com]

> Is chromium the only program with which you experience this problem?

Thanks for your answer Andrew.

Thanks to a private reply I got, I have been seen that the problem is related with my `PATH`. I have installed chromium via nix package manager, and for this reason it is not in the `PATH` that dom0 is able to see. Answering your question, it happens with any other package I installed with nix.

It doesn't happen in my VM because there I have the `PATH` configured with zsh when I log in.

So, now, the question comes down to: how could I change my VM `PATH` seen from dom0? I tried with my VM `~/.profile` and `~/.bashrc` but without success. I suspect this may be related with another topic I open some time ago:

https://groups.google.com/forum/#!topic/qubes-users/G9F3EHpeU2Q

Thank you very much

[ma...@lamarciana.com]

> I dont see this behaviour in a TemplateBased qube, or a standalone.
> In both, the browser just opens.
> That's with a standard Debian-8 template.
>
> You can try running with '-p' option to see if any errors are being
> thrown.

Thanks for your answer Unman. The issue is that I installed it with nix package manager and then it ends up in another path. Please, see my previous reply for details.

[ma...@lamarciana.com]

> Hello, did you run "Add more shortcuts" at least once (look which apps
> are there)? I got very confused by this point in another, maybe related
> situation: when changing the templateVM you *must* do so, since symbolic
> links to all apps are different in fedora and debian, for example. All
> the best, Bernhard

Thanks for your answer haaber. Yes, I run that... now I see it is related with the application PATH. Please, see previous replies for details.

[Unman]

The issue you raise there arises because the xterm is not a login shell
so will not use .profile.
It is interactive so (using bash) will use .bashrc

On the immediate question here you can always set the path explicitly:
qvm-run -p qube "export PATH=$PATH:<NEWPATH> && foo"

[ma...@lamarciana.com]

> The issue you raise there arises because the xterm is not a login shell
> so will not use .profile.
> It is interactive so (using bash) will use .bashrc
>
> On the immediate question here you can always set the path explicitly:
> qvm-run -p qube "export PATH=$PATH:<NEWPATH> && foo"

Hey Unman. The issue is that neither `~/.bashrc` nor `/etc/bash.bashrc` from my VM are used when I do `qvm-run` from dom0. Your workaround works but I think it is quite cumbersome. I wonder if there is any way to change the VM PATH seen from dom0 for every command.

Thanks

[Unman]

Yes, I know - that's why I said "using bash".
You are using zsh, so you said, so you need to put the path in ~/.zprofile

For example, with simple script 'logit' in home/user/newpath:

qvm-run -a -p qube logit
fails with "logit: not found"

append path=('home/user/newpath' $path) to ~/.zprofile
Then qvm-run succeeds

[ma...@lamarciana.com]

> Yes, I know - that's why I said "using bash".
> You are using zsh, so you said, so you need to put the path in ~/.zprofile
>
> For example, with simple script 'logit' in home/user/newpath:
>
> qvm-run -a -p qube logit
> fails with "logit: not found"
>
> append path=('home/user/newpath' $path) to ~/.zprofile
> Then qvm-run succeeds

Yeah, you are right, this works. Thank you very much. But I don't quite understand. I guess that I'm opening an interactive non-login shell, but ~/.zprofile is sourced while ~/.zshrc isn't, while, from http://zsh.sourceforge.net/Intro/intro_3.html:

> `.zshrc' is sourced in interactive shells

> [...]

> `.zlogin' is sourced in login shells. [...] `.zprofile' is similar to `.zlogin', except that it is sourced before `.zshrc'

[Unman]

try this:
qvm-run -a -p qube "echo $0"

and:
qvm-run -a -p qube "ps aux"

You may be surprised.

[ma...@lamarciana.com]

> try this:
> qvm-run -a -p qube "echo $0"

It returns `bash`

> and:
> qvm-run -a -p qube "ps aux"

It includes a `/bin/bash /usr/bin/qubes-session`

> You may be surprised.

Also, `echo $SHELL` returns `/bin/bash`.

I thought that maybe that `bash` process was in fact a subprocess of the actual `zsh` shell, but `ps aux|grep zsh` returns nothing.

So, yes, I'm very surprised, and now I understand even less why `~/.zprofile` is sourced... :)

[Unman]

I'm probably wrong but I think what's happening is this:
Look up the process list and you'll see the invocation:
su -l user -c /usr/bin/xinit.......

That's su starting a shell as a login shell: as you have zsh as default
shell, .zprofile is read to set env variables, including path.

And I think you should have seen the output from qvm-run ps aux
included something like "sh -c ps aux".
That call to sh is coming from qrexec-fork-server, I think.

I hope that makes it a little clearer.
It would be interesting to see what happened if you were to relink sh
to zsh in the template. I'm looking at a number of issues arising using
some non default user shells(tcsh, fish)

[ma...@lamarciana.com]

> I'm probably wrong but I think what's happening is this:
> Look up the process list and you'll see the invocation:
> su -l user -c /usr/bin/xinit.......

Right

> That's su starting a shell as a login shell: as you have zsh as default
> shell, .zprofile is read to set env variables, including path.
>
> And I think you should have seen the output from qvm-run ps aux
> included something like "sh -c ps aux".

Right

> That call to sh is coming from qrexec-fork-server, I think.
>
> I hope that makes it a little clearer.

Not too much, but I guess I lack some background in qubes internals :)

> It would be interesting to see what happened if you were to relink sh
> to zsh in the template. I'm looking at a number of issues arising using
> some non default user shells(tcsh, fish)

Doing so:

$ qvm-run -a -p qube "echo $0"
# => sh

$ qvm-run -a -p qube "ps aux"
# Inclues
# => /bin/bash /usr/bin/qubes-session
# => su -l user -c /usr/bin/xinit
# => ps aux (without `sh -c` before)

$ qvm-run -a -p qube 'echo $SHELL'
# => /bin/zsh

[Jean-Philippe Ouellet]

Running execsnoop [1] in the AppVM while trying to start chromium may
give you more insight into what is actually happening. Tracing
observed behavior is often easier than digging through the source.

[1]: https://raw.githubusercontent.com/brendangregg/perf-tools/master/execsnoop

[Unman]

Well yes, except that it's clear form the thread that Marc knows what
the issue is (Path not set), and I doubt execsnoop would add more
insight to that.