"Unable to find keyfile for application": clicks installed in current session don't create UAL cache, and UAL does not look for .desktop files in click pkgdir

[Martin Pitt]

For testing/autopkgtest I want/need to run click apps and their tests in a schroot or container, as the turnaround with real phones and the emulator is way too large. But in a container, ubuntu-app-launch fails with

$ ubuntu-app-launch `ubuntu-app-triplet com.ubuntu.calculator`

** (process:766): WARNING **: Unable to find keyfile for application 'com.ubuntu.calculator_calculator_1.3.283'
init: application-legacy (com.ubuntu.calculator_calculator_1.3.283-1403523098604203) pre-start process (770) terminated with status 1

In strace I see that it looks for the .desktop file in the following locations:

  /home/ubuntu/.cache/ubuntu-app-launch/desktop/com.ubuntu.calculator_calculator_1.3.283.desktop
  /home/ubuntu/.local/share/applications/com.ubuntu.calculator_calculator_1.3.283.desktop
  /usr/local/share/applications/com.ubuntu.calculator_calculator_1.3.283.desktop
  /usr/share/applications/com.ubuntu.calculator_calculator_1.3.283.desktop

but not in the click dir:

$ click pkgdir com.ubuntu.calculator
/opt/click.ubuntu.com/.click/users/@all/com.ubuntu.calculator

The workaround is to create the symlink manually, then it works:

$ ln -s `click pkgdir com.ubuntu.calculator`/*.desktop .cache/ubuntu-app-launch/desktop/`ubuntu-app-triplet com.ubuntu.calculator`.desktop
$ ubuntu-app-launch `ubuntu-app-triplet com.ubuntu.calculator`

But that's certainly not something that autopkgtest should do.

[Martin Pitt (pitti)]

Reproducer:

1. Create a suitable container:
sudo lxc-create -n click -t ubuntu -- -r utopic
sudo lxc-start -n click
# log in as ubuntu/ubuntu, then run
sudo apt-get install -y --no-install-recommends click ubuntu-sdk-libs ubuntu-app-launch{,-tools} dbus-x11 xvfb bzr ca-certificates wget
sudo poweroff

2. Start ephemeral container (so that you can run this test multiple times):
sudo lxc-start-ephemeral -o click
# log in as ubuntu/ubuntu

3. Get the current calculator .click package. I just built it myself, and as it's difficult to get the official ones, I put it on people:
wget http://people.canonical.com/~pitti/tmp/com.ubuntu.calculator_1.3.283_all.click

4. Start X server
Xvfb :5 -screen 0 1024x768x24 >/dev/null 2>&1 &
export DISPLAY=:5
export XAUTHORITY=/dev/null

5. Start upstart session:
mkdir /tmp/r
export XDG_RUNTIME_DIR=/tmp/r
# some tests fail with German locale
export LANG=en_US.UTF-8
/sbin/init --user &
sleep 1
. /tmp/r/upstart/sessions/$!.session
export UPSTART_SESSION
export DBUS_SESSION_BUS_ADDRESS=`/sbin/initctl get-env DBUS_SESSION_BUS_ADDRESS`

6. Install click package:
# avoid tripping over AppArmor restrictions in container in click hook
sudo rm /sbin/apparmor_parser
sudo click install --all-users com.ubuntu.calculator_*.click

7. Try to launch click app:
ubuntu-app-launch `ubuntu-app-triplet com.ubuntu.calculator`

This reproduces the error.

If I install the click package *before* launching upstart's user session, it *does* work. I. e. run step 6 before step 5, then upstart-app-launch (or something else) creates

lrwxrwxrwx 1 ubuntu ubuntu 102 Jun 23 13:44 .cache/ubuntu-app-launch/desktop/com.ubuntu.calculator_calculator_1.3.283.desktop -> /opt/click.ubuntu.com/.click/users/@all/com.ubuntu.calculator/com.ubuntu.calculator_calculator.desktop

So it seems this only affects click apps which get installed in an already running session.

[Martin Pitt (pitti)]

When I run "initctl start click-user-hooks" after installing the .click package, it does create the .cache/ubuntu-app-launch/desktop/ symlink, and after that it works.

However, that job only runs on session start, i. e. any click app which gets installed within the runnin session won't work until a reboot (on the phone). Could u-a-l also look into the "click pkgdir" of the given application when looking for the .desktop file, if the cache is not present?

[Ted Gould (ted)]

Seems to me that the bug here is that the click hooks for the user session aren't run when the click package is installed with --all-users. The click hook should make that symbolic link.

[Martin Pitt (pitti)]

That may be, and for speedup reason this might be considered. But it's still wrong to rely on the symlinks in ~/.cache:

 - The user might try and clean up after being low on space, and removing ~/.cache/ is a legitimate thing to do
 - With --all-users it's in no way guaranteed that you can actually access every user's home directory. They might be encrypted (ecryptfs), or on a remote storage, or you don't even know which users are on the system (LDAP and the like)

These are certainly not important use cases on today's phone, but they are on a desktop, and we are aiming for convergence here I suppose? So u-a-l still ought to also look into the click package's --pkgdir IMHO.

[Ted Gould (ted)]

On Mon, 2014-07-07 at 13:30 +0000, Martin Pitt wrote:

> That may be, and for speedup reason this might be considered. But it's
> still wrong to rely on the symlinks in ~/.cache:
>
> - The user might try and clean up after being low on space, and removing ~/.cache/ is a legitimate thing to do
> - With --all-users it's in no way guaranteed that you can actually access every user's home directory. They might be encrypted (ecryptfs), or on a remote storage, or you don't even know which users are on the system (LDAP and the like)
>
> These are certainly not important use cases on today's phone, but they
> are on a desktop, and we are aiming for convergence here I suppose? So
> u-a-l still ought to also look into the click package's --pkgdir IMHO.

I think ~/.cache is a good place :-) We may have to agree to disagree on
this, but here are my arguments.

 - We don't want the symbolic links backed up. Backup utilities like
deja-dup ignore ~/.cache (correctly).
 - The symbolic links are by machines for machines, so they can be
recreated at anytime, so they don't qualify as user data.
 - If for some reason a user did decide to delete their ~/.cache
directory the symbolic links would be recreated on the next login
 - If a package is installed with all-users the symbolic link will be
created the next time a user logs in, before apps could get launched.

In general the reason to use the cache directory at all is an
optimization, we don't want to open up the click database for every
launch of an application to determine its package directory. It's too
expensive. So we use the cache to do just that, provide a cache on how
to launch the app.

I'm not against having a slower path if the cache is determined to be
destroyed or invalid, but I think that'd be a "nice to have" not a
priority feature and would delay starting up of legacy apps so it would
have to have the cost determined (perhaps we don't care about it?).

[Martin Pitt (pitti)]

> I think ~/.cache is a good place :-)

Yes, I do agree. I'm not saying at all that u-a-l shouldn't look into this. Just that it needs to fall back to looking into the click package dir if there is no cached symlink.

> and would delay starting up of legacy apps

How would that be? If there's no symlink in ~/.cache/ the startup currently does not work at all. With a fallback to pkgdir it would work, just a tad slower (that's why we have the cache). But again, you can't rely that all user's ~/.cache/ directories are accessible at the time of installing a click (that's the use case that doesn't affect current phone so much, but convergence, so is low-prio), but the issue which *does* affect the phone is installing a click and trying to start it in the current session (as the upstart hook doesn't run then).

[Ted Gould (ted)]

On Thu, 2014-07-10 at 14:01 +0000, Martin Pitt wrote:

> > and would delay starting up of legacy apps
>
> How would that be? If there's no symlink in ~/.cache/ the startup
> currently does not work at all. With a fallback to pkgdir it would work,
> just a tad slower (that's why we have the cache). But again, you can't
> rely that all user's ~/.cache/ directories are accessible at the time of
> installing a click (that's the use case that doesn't affect current
> phone so much, but convergence, so is low-prio), but the issue which
> *does* affect the phone is installing a click and trying to start it in
> the current session (as the upstart hook doesn't run then).

The way it works today is that it checks the cache and starts either the
application-click or application-legacy Upstart job which handles the
specifics of each type. It chooses this based on whether there is an
entry in the cache with application-legacy being the fallback. If we add
a step based on the Click DB before we get to that fallback it will be
delayed.

We don't rely on the Upstart hook, we rely on a Click hook. The Click
hook runs in two places, when the package is installed or when the
session is started. So if the cache is not available when the Click is
installed then it is run when the session is started. If the user
session is open (for instance on the phone) the Click hook is run
immediately on install and the cache is up-to-date.

[Martin Pitt (pitti)]

Ted Gould [2014-07-10 19:01 -0000]:
> If the user session is open (for instance on the phone) the Click
> hook is run immediately on install and the cache is up-to-date.

Ah ok, so that seems to be the bit which is broken in some cases then?

Thanks for the explanation!

Martin

[Ted Gould (ted)]

On Fri, 2014-07-11 at 04:22 +0000, Martin Pitt wrote:

> Ted Gould [2014-07-10 19:01 -0000]:
> > If the user session is open (for instance on the phone) the Click
> > hook is run immediately on install and the cache is up-to-date.
>
> Ah ok, so that seems to be the bit which is broken in some cases then?

Yes, I think that it's not being run with --all-users, where it should
be run for all logged in users in that case.

[Ted Gould (ted)]

I think this bug has been fixed and is just old. Marking as invalid across the board.

[Martin Pitt (pitti)]

This bug has not been fixed. The reproducer in comment 1 still proves that (in current vivid). That reproducer is a bit complicated, but I wanted to have one which doesn't require an actual phone. But you can easily reproduce that on an actual phone, too. Since I don't have another click at hand, I just use the calculator and pretend it wasn't installed already:

Uninstall the preinstalled calculator and remove the cache:

sudo rm -r /usr/share/click/preinstalled/com.ubuntu.calculator
rm ~/.cache/ubuntu-app-launch/desktop/com.ubuntu.calculator_calculator_*.desktop

It's now gone from "click list". Now install it again from an actual .click:

wget http://people.canonical.com/~pitti/tmp/com.ubuntu.calculator_1.3.283_all.click
sudo click install --all-users --allow-unauthenticated com.ubuntu.calculator_1.3.283_all.click

There's an error about "Could not parse click manifest." for a mismatching version, but that's fine. "click list" should now show that com.ubuntu.calculator 1.3.283 is installed.

Note that ~ .cache/ubuntu-app-launch/desktop/ doesn't have a cached entry for the calculator, as it was installed in a running session. And it indeed can't be started due to that bug:

$ ubuntu-app-launch `ubuntu-app-triplet com.ubuntu.calculator`

** (process:5499): WARNING **: Unable to find keyfile for application 'com.ubuntu.calculator_calculator_1.3.283'

Clicking on the calculator icon in the dash doesn't work either.

[Ted Gould (ted)]

I don't think this is a UAL bug. I think the click hook should be run on install which it isn't. I think that it's reasonable for UAL to depend on its click hook running.