the gox classic snap gets stuck consuming a lot of cpu

[Leo Arias]

I'm trying to make a snap for gox: https://github.com/mitchellh/gox

It needs to call the go binary installed in the system, so I made it classic. Attached is the yaml to make the snap. Build it with snapcraft, install it with --classic and:

$ taskset 2 gox -h

(taskset to avoid the bug with multiple cores that Chipaca is investigating.)

It just gets stuck there consuming CPU, check with top.

[Leo Arias (elopio)]

This affects also the gopass snap:

$ sudo apt install git snapcraft
$ cd /tmp
$ git clone --recursive https://github.com/elopio/gopass
$ cd gopass
$ git checkout snapcraft
$ cd dist/snap
$ snapcraft
$ sudo snap install *.snap --dangerous --classic
$ gopass -h

[Ken VanDine (ken-vandine)]

I can confirm this issue. I'm having the same problem with my gnome-calendar and gnome-contacts classic snaps.

[Zygmunt Krynicki (zyga)]

This is caused by snapcraft and the fact that this snap is using classic confinement.

The generated wrapper script has this content:

zyga@fyke:~/snapd$ cat /snap/gox/current/command-gox.wrapper
#!/bin/sh
exec "gox" "$@"

Since classic confinement does not reset PATH (because it cannot) gox is being resolved to /snap/bin/gox again, which causes exec/fork loop.

My suggestion would be to generate no wrappers for classic confinement or to warn people about this at build time.

[Leo Arias (elopio)]

oh, nice finding. Thanks zyga.

mvo has a pr in progress to not generate the wrapper: https://github.com/snapcore/snapcraft/pull/1420

@sergiusens, should classic skip the wrapper by default?

[Sergio Schvezov (sergiusens)]

This is known issue, generating no wrappers is a no go as we will loose functionality such as creating commands of the type

    command: env PATH=$SNAP/bin my-command

which is not allowed in snap.yaml

[Leo Arias (elopio)]

With bin/ in the command, gox works and I could propose it upstream:
https://github.com/mitchellh/gox/pull/89