Python snaps now failing with snapcraft 2.27.1

[Stuart Bishop]

Snaps using the Python plugin and classic containment fail if built with snapcraft 2.27.1, hanging indefinitely when run with no output apart from this syslog entry:

Mar 2 16:00:29 uurp juju-act[21034]: cmd.go:111: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
Mar 2 16:00:29 uurp kernel: [16328.264311] audit: type=1400 audit(1488445229.488:473): apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/tty" pid=21034 comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0

I first picked this up with a Launchpad built snap, but can reproduce it locally.

For an example, see https://git.launchpad.net/juju-act/tree/ which is quite minimal. I will attach a snap built with a previous version of snapcraft that works fine, and a snap built with 2.27.1 that hangs.

[Stuart Bishop (stub)]

Here is a working snap. This is the same as the 'juju-act' snap published in the store.

[Stuart Bishop (stub)]

This is a snap built from the same source that now fails. I don't know if this is a snapcraft issue, or if one of the python dependencies pulled in by the python plugin is now failing. The only dependency in this Python app is PyYAML.

[Seth Arnold (seth-arnold)]

Are there differences in the execution environment of the two snaps in question? Was one executed via tmux or screen and the other not? via xterms on the host or ssh -X forwarded terminals? Or console vs terminals?

Thanks

[Stuart Bishop (stub)]

No, its all the same execution environment. Install snap a, works. Install snap b, hangs. Install snap a, works again.

[Michael Hudson-Doyle (mwhudson)]

The snaps are quite different: http://paste.ubuntu.com/24098150/.
juju_act.py not being in the broken snap certainly doesn't look good?

On 3 March 2017 at 09:40, Stuart Bishop <email address hidden> wrote:

> No, its all the same execution environment. Install snap a, works.
> Install snap b, hangs. Install snap a, works again.
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snapcraft.
> https://bugs.launchpad.net/bugs/1669306
>
> Title:
> Python snaps now failing with snapcraft 2.27.1
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapcraft/+bug/1669306/+subscriptions
>

[Stuart Bishop (stub)]

Sorry, I must have uploaded the wrong fail snap in the confusion.

Here is the snapdiff between _working and _failing: http://pastebin.ubuntu.com/24100448/ . My money is on sitecustomize.py changes.

However, I can't see how sitecustomize.py gets found:

$ snap run --shell juju-act
$ env | grep PYTHON
$ which python3
/usr/bin/python3
$ exit
$ cat /snap/juju-act/current/command-juju-act.wrapper
#!/bin/sh
exec "juju-act" "$@"

[Sergio Schvezov (sergiusens)]

Stuart, to get the correct `which python3` result please open the command wrapper that was created for this app entry and export all those entries into the environment.

Also, what is the shebang of juju-act IN the snap?

The way sitecustomize is found is because python in its core has logic to find its PYTHONHOME relative to the interpreter.

[Stuart Bishop (stub)]

Per comment #6, there is no environment configuration at all in the wrapper:

# cat command-juju-act.wrapper
#!/bin/sh
exec "juju-act" "$@"

The shebang of juju-act in the snap:

$ head -1 /snap/juju-act/current/bin/juju-act
#!/usr/bin/env python3

I can extract the environment settings from the working snap's command-juju-act.wrapper, and execute it manually inside the failing snap via snap run. If I do this, I can execute the Python script. It seems that the problem is that with snapcraft 2.27.1 the necessary environment is not being setup in the command wrapper. As I can reproduce this using Launchpad, it is no a problem with my local sysetm.

[Stuart Bishop (stub)]

https://code.launchpad.net/~stub/+snap/juju-act has the Launchpad built snaps, which also demonstrate this behaviour.

[Sergio Schvezov (sergiusens)]

I didn't read `confinement: classic` before, this changes everything. The behavior of `classic` is marked as experimental to give us some space to allow changes until we find a common denominator that works for all projects.

If `command` in `prime/meta/snap.yaml` for the `apps` entry doesn't start with <path>/python3 I suspect something is going wrong (and we can fix that if python3 is indeed in prime). In the meantime, does changing command to:

`command: $SNAP/usr/bin/python3 $SNAP/bin/juju-act`

solve the running problem?

[Stuart Bishop (stub)]

The apps section of prime/meta/snap.yaml does not mention python3 at all:

apps:
  juju-act:
    command: command-juju-act.wrapper

Setting the command in snapcraft.yaml per above fails to build:

[Errno 2] No such file or directory: '/home/stub/src/juju-act/prime/$SNAP/usr/bin/python3'

If I set command: to '/usr/bin/python3 $SNAP/bin/juju-act', the built snap works fine as expected. The resulting wrapper is calling the correct python3 (although there is a double // that might be a worry):

#!/bin/sh
exec "$SNAP//usr/bin/python3" $SNAP/bin/juju-act "$@"

[Sergio Schvezov (sergiusens)]

On Tue, 7 Mar 2017 16:40:06 +0000, Stuart Bishop wrote:
> The apps section of prime/meta/snap.yaml does not mention python3 at
> all:
>
> apps:
> juju-act:
> command: command-juju-act.wrapper
>
>
> Setting the command in snapcraft.yaml per above fails to build:
>
> [Errno 2] No such file or directory: '/home/stub/src/juju-
> act/prime/$SNAP/usr/bin/python3'

> If I set command: to '/usr/bin/python3 $SNAP/bin/juju-act', the
> built snap works fine as expected. The resulting wrapper is
> calling the correct python3 (although there is a double // that
> might be a worry):
>
> #!/bin/sh
> exec "$SNAP//usr/bin/python3" $SNAP/bin/juju-act "$@"

Silly me, you can either do `usr/bin/python3 $SNAP/bin/juju-act` or `/usr/bin/env $SNAP/usr/bin/python3 $SNAP/bin/juju-act`.

I'll look into making this experience a better one.

--
Sent using Dekko from my Ubuntu device