Re: Further ABI-related issues for ldc2 snap on 14.04 ... ?

2017-03-10 Thread Joseph Rushton Wakeling 

On 05/03/17 14:10, Sergio Schvezov wrote:

I think you have come to a cross roads where you will need to choose to either
always use the linker from the core snap and link to things from your snap or
provide multiple zlib targets for different versions of glibc (or any other
library you want to link with and provide it in your snap).

If you are going to have things like
/snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 you would certainly want
to use the linker in core. If you are going to use /usr/bin/gcc you probably
shouldn't include libraries from `/snap/...`.

I am sorry that I cannot help you more without deep diving into your project.


First off, no need for apologies.  This is obviously quite an esoteric issue, 
and I shared it more with the thought that it might be interesting than with any 
expectation that anyone would be able to help.  You've already been super 
generous with your time and support!


I'm not sure I follow what you mean by "use the linker from the core snap". 
AFAICS the core snap doesn't contain ld or gcc or any toolchain ... ?


If you mean when building the contents of the snap, I'm just doing a regular 
`snapcraft cleanbuild`, no special magic to select particular gcc or binutils 
versions.



--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: kpi dashboard available?

2017-03-10 Thread Evan Dandrea 
On Fri, 10 Mar 2017 at 10:14 Adam Stokes  wrote:

Is there an available kpi dashboard I can take a look at? I'm interested to
see where conjure-up sits in the snap statistics.


Hi Adam,

Your best bet today is the Stats page on
https://myapps.developer.ubuntu.com/, but we're working to provide a much
richer set of metrics going forward. For example, you'll be able to see
unique active installs broken down by channel, architecture, and revision.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Class confinement for Python snaps

2017-03-10 Thread Steve Langasek 
On Fri, Mar 10, 2017 at 04:02:54PM +, Sergio Schvezov wrote:
> On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote:
> > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm
> > running into some problems.  ubuntu-image is a Python 3 application, and I'm
> > using snapcraft 2.27.1+17.4 on Zesty.

> Any reaosn you are moving from devmode to classic?  The progression should
> be classic->devmode->strict

ubuntu-image is a commandline tool that operates on arbitrary files on the
filesystem at the user's instruction.  This seems to be in the wheelhouse
for classic snaps - and certainly, the /tmp issue is very confusing for
users and AFAICS isn't truly solvable outside of classic mode.

Given this, I don't see any reason we would want to move ubuntu-image from
classic to strict mode.  Do you disagree?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Class confinement for Python snaps

2017-03-10 Thread Barry Warsaw 
On Mar 10, 2017, at 04:52 PM, Didier Roche wrote:

>Note as well that I opened https://bugs.launchpad.net/snapcraft/+bug/1670388
>against the snapcraft project a couple of days ago.  I think snapcraft should
>at least fail the build to warn you about this.

Thanks, subscribed!
-Barry

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Class confinement for Python snaps

2017-03-10 Thread Barry Warsaw 
On Mar 10, 2017, at 04:02 PM, Sergio Schvezov wrote:

>Any reaosn you are moving from devmode to classic? The progression should be
>classic->devmode->strict

A couple of reasons.  Probably the most problematic one is that /tmp inside
the snap is not the same as /tmp outside the snap, and we have a bunch of
crufty workarounds to fail early (when possible) if those directories are used
to communicate information across the boundaries.

ubuntu-image builds core images.  People like to put their extra snaps, or
their models in /tmp, or write the resulting images to /tmp.  All of that
works with the u-i deb but doesn't work with the u-i snap.   I *think* we've
identified most of the places where this happens, so we can issue an error and
exit, but it's an unfortunate asymmetry between the snap and the deb.  (And
I'm not 100% sure we've identified all the cases; and it makes the code more
complicated, etc.)

>It is however unfortunate that classic confined snaps can make it to the
>stable channel while devmode ones cannot

That's another limitation I was hoping to eliminate with the switch to
classic.  Currently we use edge as our "beta" release channel, then we do any
manual QA against that, and promote to beta for our blessed release.  I'd
love to be able to push the blessed version to stable, since it's way more
discoverable.

>, maybe we need an alias for devmode (which would be as secure as classic
>confinment but with the common root as root) as in some cases it is an
>improvement over classic (not needing to deal with libraries and installable
>on Ubuntu Core).

Isn't classic supposed to be a more or less replacement for traditional debs?
I probably misunderstand its purpose but our thinking was that we could bundle
it up as a classic snap as a possible, eventual, replacement for SRUing the
debs back to X and Y (and soon, Z also).  I didn't realize that classic is
viewed as the first stepping stone to strict confinement.

Cheers,
-Barry

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Class confinement for Python snaps

2017-03-10 Thread Sergio Schvezov 
On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote:
> I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm
> running into some problems.  ubuntu-image is a Python 3 application, and I'm
> using snapcraft 2.27.1+17.4 on Zesty.

Any reaosn you are moving from devmode to classic? The progression should be 
classic->devmode->strict

It is however unfortunate that classic confined snaps can make it to the stable 
channel while devmode ones cannot, maybe we need an alias for devmode (which 
would be as secure as classic confinment but with the common root as root) as 
in some cases it is an improvement over classic (not needing to deal with 
libraries and installable on Ubuntu Core).

-- 
Sent using Dekko from my Ubuntu device

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Class confinement for Python snaps

2017-03-10 Thread Didier Roche 

Le 10/03/2017 à 16:14, Barry Warsaw a écrit :

I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm
running into some problems.  ubuntu-image is a Python 3 application, and I'm
using snapcraft 2.27.1+17.4 on Zesty.

The first problem I'm having is I think directly related to LP: #1670749.


Hey Barry,
Note as well that I opened 
https://bugs.launchpad.net/snapcraft/+bug/1670388 against the snapcraft 
project a couple of days ago.

I think snapcraft should at least fail the build to warn you about this.

Cheers,
Didier


   I
ended up reopening this because while Corey found that he ultimately only
needed to set the $PATH environment variable, I still also had to $PYTHONPATH
and I had to make sure the snap versions come before the system versions:

environment:
   PATH: $SNAP/bin/:$PATH
   PYTHONPATH: $SNAP/lib/python3.5/site-packages:$PYTHONPATH

This gets me pretty close, but then I run into my second problem which is that
we depend on pyparted, in Ubuntu as python3-pyparted.  This package contains
both Python source and an extension module and to further complicate things,
its tarball is only released on GitHub, not on PyPI, so adding it to
python-packages in the ubuntu-image part doesn't work.  Further, it doesn't
help to add python3-parted to stage-packages because it appears that with
classic confinement, none of those Python packages end up in the snap.

I tried to add a scriptlet to copy things over, but that also fails.  E.g.:

parts:
   ubuntu-image:
 plugin: python
 source: https://github.com/CanonicalLtd/ubuntu-image.git
 source-type: git
 python-packages:
   - PyYAML
   - attrs
   - voluptuous
 prime:
   - bin/ubuntu-image
   - usr
   - lib
   - sbin
 stage-packages:
   - e2fsprogs
   - mtools
   - python3-debian
   - python3-parted
   - util-linux
 install: |
   cp -a ../install/usr/lib/python3/dist-packages/parted 
../stage/lib/python3.5/site-packages
   cp -a ../install/usr/lib/python3/dist-packages/pyparted-*.egg-info 
../stage/lib/python3.5/site-packages

$ snapcraft
...
/home/barry/projects/ubuntu/allsnappy/ubuntu-image/parts/ubuntu-image/build
cp: cannot create directory '../stage/lib/python3.5/site-packages': No such 
file or directory
cp: cannot create regular file '../stage/lib/python3.5/site-packages': No such 
file or directory
Command '['/bin/sh', '/tmp/tmpfeczxcco', '/tmp/tmp2__1bdau']' returned non-zero 
exit status 1

This happens because ./stage/ is empty at the point that the install scriptlet
is run.

I can think of a couple of approaches that might be useful.

* Allow python-packages specifications to pip install from repositories other
   than PyPI.

* Allow python-packages to come from git and/or https URLs (I tried this and
   it didn't work).

* Integrate dirtbike and wheels into the Python parts building phases.
   (dirtbike is a tool that Debian/Ubuntu uses in very limited cases to turn
   installed distro packages into .whl files.)

* Provide a scriptlet hook that runs after the normal part installation step.

My current WIP snapcraft.yaml file is here:

https://github.com/CanonicalLtd/ubuntu-image/blob/lp1638645/snapcraft.yaml

I'm going to keep trying a few things, but any suggestions are welcome.  I'm
happy to file bugs as needed.

Cheers,
-Barry




--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Class confinement for Python snaps

2017-03-10 Thread Barry Warsaw 
I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm
running into some problems.  ubuntu-image is a Python 3 application, and I'm
using snapcraft 2.27.1+17.4 on Zesty.

The first problem I'm having is I think directly related to LP: #1670749.  I
ended up reopening this because while Corey found that he ultimately only
needed to set the $PATH environment variable, I still also had to $PYTHONPATH
and I had to make sure the snap versions come before the system versions:

environment:
  PATH: $SNAP/bin/:$PATH
  PYTHONPATH: $SNAP/lib/python3.5/site-packages:$PYTHONPATH

This gets me pretty close, but then I run into my second problem which is that
we depend on pyparted, in Ubuntu as python3-pyparted.  This package contains
both Python source and an extension module and to further complicate things,
its tarball is only released on GitHub, not on PyPI, so adding it to
python-packages in the ubuntu-image part doesn't work.  Further, it doesn't
help to add python3-parted to stage-packages because it appears that with
classic confinement, none of those Python packages end up in the snap.

I tried to add a scriptlet to copy things over, but that also fails.  E.g.:

parts:
  ubuntu-image:
plugin: python
source: https://github.com/CanonicalLtd/ubuntu-image.git
source-type: git
python-packages:
  - PyYAML
  - attrs
  - voluptuous
prime:
  - bin/ubuntu-image
  - usr
  - lib
  - sbin
stage-packages:
  - e2fsprogs
  - mtools
  - python3-debian
  - python3-parted
  - util-linux
install: |
  cp -a ../install/usr/lib/python3/dist-packages/parted 
../stage/lib/python3.5/site-packages
  cp -a ../install/usr/lib/python3/dist-packages/pyparted-*.egg-info 
../stage/lib/python3.5/site-packages

$ snapcraft
...
/home/barry/projects/ubuntu/allsnappy/ubuntu-image/parts/ubuntu-image/build
cp: cannot create directory '../stage/lib/python3.5/site-packages': No such 
file or directory
cp: cannot create regular file '../stage/lib/python3.5/site-packages': No such 
file or directory
Command '['/bin/sh', '/tmp/tmpfeczxcco', '/tmp/tmp2__1bdau']' returned non-zero 
exit status 1

This happens because ./stage/ is empty at the point that the install scriptlet
is run.

I can think of a couple of approaches that might be useful.

* Allow python-packages specifications to pip install from repositories other
  than PyPI.

* Allow python-packages to come from git and/or https URLs (I tried this and
  it didn't work).

* Integrate dirtbike and wheels into the Python parts building phases.
  (dirtbike is a tool that Debian/Ubuntu uses in very limited cases to turn
  installed distro packages into .whl files.)

* Provide a scriptlet hook that runs after the normal part installation step.

My current WIP snapcraft.yaml file is here:

https://github.com/CanonicalLtd/ubuntu-image/blob/lp1638645/snapcraft.yaml

I'm going to keep trying a few things, but any suggestions are welcome.  I'm
happy to file bugs as needed.

Cheers,
-Barry


pgpxYdDtYgwWN.pgp
Description: OpenPGP digital signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Request for help / ideas to debug issue

2017-03-10 Thread Alfonso Sanchez-Beato 
On Fri, Mar 10, 2017 at 10:22 AM, John Lenton 
wrote:

> Hello!
>
> We're seeing a weird issue with either go, pthreads, or the kernel. If
> you're knowledgeable about one or more of those things, could you take
> a look? Thank you.
>
> The issue manifests as nasty warnings from the "snap run" command,
> which is also the first step into a snapped app or service. It looks
> like
>
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
>
> a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/
>
> build that, run it in a loop, and you'll see a bunch of those messages
> (and some weirder ones, but let's take it one step at a time).
>
> if you comment out the 'import "C"' line the message will change but
> still happen, which makes me think that at least in part this is a Go
> issue (or that we're holding it wrong).
>
> Note that the exec does work; the warning seems to come from a
> different thread than the one doing the Exec (the other clue that
> points in this direction is that sometimes the message is truncated).
> You can verify the fact that it does run by changing the /bin/true to
> /bin/echo os.Args[1], but because this issue is obviously a race
> somewhere, this change makes it less likely to happen (from ~10% down
> to ~.5% of runs, in my machines).
>
> One thing that makes this harder to debug is that strace'ing the
> process hangs (hard, kill -9 of strace to get out) before reproducing
> the issue. This probably means we need to trace it at a lower level,
> and I don't know enough about tracing a process group from inside the
> kernel to be able to do that; what I can find about kernel-level
> tracing is around syscalls or devices.
>
> Ideas?
>

I found this related thread:

https://groups.google.com/forum/#!msg/golang-nuts/8gszDBRZh_4/lhROTfN9TxIJ

<<
I believe this can happen on GNU/Linux if your program uses cgo and if
thread A is in the Go runtime starting up a new thread B while thread
C is execing a program.  The underlying cause is that while one thread
is calling exec the Linux kernel will fail attempts by other threads
to call clone by returning EAGAIN.  (Look for uses of the in_exec
field in the kernel sources.)
>>

Something like adding a little sleep removes the traces, for instance:

http://paste.ubuntu.com/24151637/

where the program run sleep for 1ms before calling Exec. For smaller units
(say, 20 us) the issue still happens.

It looks to me that right before running main(), go creates some threads,
calling clone() and probably getting the race described in the thread. As
anyway you are running Exec I guess the traces are harmless, you do not
need the go threads. Nonetheless, I think that the go run time should retry
instead of printing that trace.


>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: workaround for connect no autoconnect interfaces without login on system

2017-03-10 Thread knitzsche 

Hi Jamie

On 03/10/2017 07:20 AM, Jamie Strandboge wrote:

Gadget developers are supposed to have a voice in what is autoconnected on
their
devices and it seems that Nicolino is asking for advice on how to make that
happen. This comes up from time to time so once there is a definitive answer,
this sounds like a great opportunity for some documentation. :)


Do you, or does anyone, know how to auto connect from a gadget snap?

Cheers,
Kyle

--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: workaround for connect no autoconnect interfaces without login on system

2017-03-10 Thread Jamie Strandboge 
On Tue, 2017-03-07 at 13:41 -0600, Jamie Strandboge wrote:
> On Tue, 2017-03-07 at 15:05 +, Nicolino Curalli wrote:
> > 
> > Hi kyleN
> > thanks so much for the answer.
> > 
> > A question for go ahead from my side:
> > how can I request the store to add an auto connection statement to the
> > snap declaration assertion ?
> Just ask on this list. :)
> 
> Looking at your previous email, it seems you would like to have the nmap snap
> auto-connected. The nmap snap is requesting a lot of privilege by plugging the
> 'network-control' interface and the snap is not coming from a trusted upstream
> or publisher. I therefore think that it correctly requires the user to
> explicitly connect the interface by default.
> 
> Based on your previous email (and my previous response) it sounds like you are
> developing a gadget snap for a particular device though. The gadget auto-
> connect 
> mechanism is therefore what you want to use since gadget snaps have a voice in
> auto-connection. I expect someone to respond to my previous email on how you
> can
> do this.
> 

The above email mistakenly was discarded by the mailing list server. Hopefully
resending this now will allow the conversation to pick up again.

> > 
> > 
> > Il 07/03/2017 15:20, knitzsche ha scritto:
> > > 
> > > 
> > > I don't think the prepare-device script can be used to auto connect, 
> > > probably because it runs confined.
> > > 
> > > You can request the store to add an auto connection statement to the 
> > > snap declaration assertion.
> > > 
> > > Cheers
> > > kyleN
> > > 
> > > 
> > > On 03/07/2017 05:19 AM, Nicolino Curalli wrote:
> > > > 
> > > > 
> > > > Hi all,
> > > > I implemented hints from James but it doesn't works.
> > > > 
> > > > I create a new gadget snap based on pc gadget for amd64, adding a hook
> > > > directory with a prepare-device hook script.
> > > > I make this script executable.
> > > > I build  an image containg my gadget (domotz-pc), pc-kernel and nmap
> > > > snap
> > > > from store.
> > > > 
> > > > The layout of my new gadget snap ( named domotz-pc )  just installed is
> > > > :
> > > > 
> > > > ./
> > > > 
> > > > -rwxr-xr-x 1 root root 753 Mar  7 00:04 meta/gadget.yaml
> > > > -rw-r--r-- 1 root root 230 Mar  7 09:11 meta/snap.yaml
> > > > 
> > > > meta/gui:
> > > > 
> > > > -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png
> > > > 
> > > > meta/hooks:
> > > > 
> > > > -rwxr-xr-x 1 root root 134 Mar  7 09:09 prepare-device
> > > > 
> > > > The prepare-device script content is:
> > > > 
> > > > --
> > > > #!/bin/sh
> > > > 
> > > > # enabling network-control interface slot for nmap network-control plug
> > > > snap connect nmap:network-control :network-control
> > > > --
> > > > 
> > > > After the registration of board by console-conf i find the following I
> > > > find the following situation on interface side:
> > > > 
> > > > :network   nmap
> > > > :network-bind  nmap
> > > > -  nmap:network-control
> > > > 
> > > > instead
> > > > 
> > > > :network   nmap
> > > > :network-bind  nmap
> > > > :network-control  nmap
> > > > 
> > > > as I wish.
> > > > 
> > > > I also  have  the following error from Apparmor:
> > > > 
> > > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353:
> > > > DEBUG: Running task 77 on Do: Run prepare-device hook
> > > > Mar  7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400
> > > > audit(1488853390.962:25): apparmor="DENIED" operation="exec"
> > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap"
> > > > pid=1428
> > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
> > > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG:
> > > > 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz-
> > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-
> > > > pc/x1/meta/hooks/prepare-
> > > > device: snap: Permission denied
> > > > Mar  7 02:28:08 localhost systemd[1]: Starting Update resolvconf for
> > > > networkd DNS...
> > > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Network configuration
> > > > changed, trying to establish connection.
> > > > Mar  7 02:28:08 localhost systemd[1]: Started Update resolvconf for
> > > > networkd DNS.
> > > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time
> > > > server 91.189.94.4:123 (ntp.ubuntu.com).
> > > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353:
> > > > DEBUG: Running task 80 on Do: Run prepare-device hook
> > > > Mar  7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400
> > > > audit(1488853690.938:26): apparmor="DENIED" operation="exec"
> > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap"
> > > > pid=1455
> > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
> > > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG:
> > > > 2017-03-07T02:28:10Z ERROR run hook

Re: workaround for connect no autoconnect interfaces without login on system

2017-03-10 Thread Jamie Strandboge 

Resending since this (and a few other emails) got caught up in a filter that was
recently activated for this list.

On Tue, 2017-03-07 at 08:36 -0600, Jamie Strandboge wrote:
> On Tue, 2017-03-07 at 09:19 -0500, knitzsche wrote:
> > 
> > I don't think the prepare-device script can be used to auto connect, 
> > probably because it runs confined.
> > 
> > You can request the store to add an auto connection statement to the 
> > snap declaration assertion.
> Well, that is a technical solution but this is a big hammer since it means all
> users of the snap don't have a say in the connection of the interface[1]
> (things
> are set to manually connect for a reason :).
> 
> Gadget developers are supposed to have a voice in what is autoconnected on
> their
> devices and it seems that Nicolino is asking for advice on how to make that
> happen. This comes up from time to time so once there is a definitive answer,
> this sounds like a great opportunity for some documentation. :)
> 
> [1] of course they can manually disconnect after the fact, but users need to
> know to do this
> 
> > 
> > 
> > On 03/07/2017 05:19 AM, Nicolino Curalli wrote:
> > > 
> > > 
> > > Hi all,
> > > I implemented hints from James but it doesn't works.
> > > 
> > > I create a new gadget snap based on pc gadget for amd64, adding a hook
> > > directory with a prepare-device hook script.
> > > I make this script executable.
> > > I build  an image containg my gadget (domotz-pc), pc-kernel and nmap snap
> > > from store.
> > > 
> > > The layout of my new gadget snap ( named domotz-pc )  just installed is :
> > > 
> > > ./
> > > 
> > > -rwxr-xr-x 1 root root 753 Mar  7 00:04 meta/gadget.yaml
> > > -rw-r--r-- 1 root root 230 Mar  7 09:11 meta/snap.yaml
> > > 
> > > meta/gui:
> > > 
> > > -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png
> > > 
> > > meta/hooks:
> > > 
> > > -rwxr-xr-x 1 root root 134 Mar  7 09:09 prepare-device
> > > 
> > > The prepare-device script content is:
> > > 
> > > --
> > > #!/bin/sh
> > > 
> > > # enabling network-control interface slot for nmap network-control plug
> > > snap connect nmap:network-control :network-control
> > > --
> > > 
> > > After the registration of board by console-conf i find the following I
> > > find
> > > the following situation on interface side:
> > > 
> > > :network   nmap
> > > :network-bind  nmap
> > > -  nmap:network-control
> > > 
> > > instead
> > > 
> > > :network   nmap
> > > :network-bind  nmap
> > > :network-control  nmap
> > > 
> > > as I wish.
> > > 
> > > I also  have  the following error from Apparmor:
> > > 
> > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353:
> > > DEBUG: Running task 77 on Do: Run prepare-device hook
> > > Mar  7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400
> > > audit(1488853390.962:25): apparmor="DENIED" operation="exec"
> > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1428
> > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
> > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG:
> > > 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz-
> > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-
> > > device: snap: Permission denied
> > > Mar  7 02:28:08 localhost systemd[1]: Starting Update resolvconf for
> > > networkd DNS...
> > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Network configuration
> > > changed, trying to establish connection.
> > > Mar  7 02:28:08 localhost systemd[1]: Started Update resolvconf for
> > > networkd
> > > DNS.
> > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time
> > > server 91.189.94.4:123 (ntp.ubuntu.com).
> > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353:
> > > DEBUG: Running task 80 on Do: Run prepare-device hook
> > > Mar  7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400
> > > audit(1488853690.938:26): apparmor="DENIED" operation="exec"
> > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1455
> > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
> > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG:
> > > 2017-03-07T02:28:10Z ERROR run hook "prepare-device": /snap/domotz-
> > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-
> > > device: snap: Permission denied
> > > Mar  7 02:33:07 localhost systemd[1]: Starting Update resolvconf for
> > > networkd DNS...
> > > Mar  7 02:33:07 localhost systemd-timesyncd[795]: Network configuration
> > > changed, trying to establish connection.
> > > Mar  7 02:33:07 localhost systemd[1]: Started Update resolvconf for
> > > networkd
> > > DNS.
> > > Mar  7 02:33:07 localhost systemd-timesyncd[795]: Synchronized to time
> > > server 91.189.94.4:123 (ntp.ubuntu.com).
> > > Mar  7 02:33:10 localhost /usr/lib/snapd/snapd[936]:

Re: Request for help / ideas to debug issue

2017-03-10 Thread Sergio Schvezov 
On Fri, 10 Mar 2017 09:22:45 +, John Lenton wrote:
> Hello!
>
> We're seeing a weird issue with either go, pthreads, or the kernel. If
> you're knowledgeable about one or more of those things, could you take
> a look? Thank you.
>
> The issue manifests as nasty warnings from the "snap run" command,
> which is also the first step into a snapped app or service. It looks
> like
>
> runtime/cgo: pthread_create failed: Resource temporarily unavailable
>
> a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/
>
> build that, run it in a loop, and you'll see a bunch of those messages
> (and some weirder ones, but let's take it one step at a time).
>
> if you comment out the 'import "C"' line the message will change but
> still happen, which makes me think that at least in part this is a Go
> issue (or that we're holding it wrong).
>
> Note that the exec does work; the warning seems to come from a
> different thread than the one doing the Exec (the other clue that
> points in this direction is that sometimes the message is truncated).
> You can verify the fact that it does run by changing the /bin/true to
> /bin/echo os.Args[1], but because this issue is obviously a race
> somewhere, this change makes it less likely to happen (from ~10% down
> to ~.5% of runs, in my machines).
>
> One thing that makes this harder to debug is that strace'ing the
> process hangs (hard, kill -9 of strace to get out) before reproducing
> the issue. This probably means we need to trace it at a lower level,
> and I don't know enough about tracing a process group from inside the
> kernel to be able to do that; what I can find about kernel-level
> tracing is around syscalls or devices.
>
> Ideas?

Aside from being able to reproduce what you see I have done no analysis against 
this but may I sugges using bcc[1] instead of strace? There's a snap for it too 
;-)

[1] https://github.com/iovisor/bcc

-- 
Sent using Dekko from my Ubuntu device

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Request for help / ideas to debug issue

2017-03-10 Thread John Lenton 
Hello!

We're seeing a weird issue with either go, pthreads, or the kernel. If
you're knowledgeable about one or more of those things, could you take
a look? Thank you.

The issue manifests as nasty warnings from the "snap run" command,
which is also the first step into a snapped app or service. It looks
like

runtime/cgo: pthread_create failed: Resource temporarily unavailable

a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/

build that, run it in a loop, and you'll see a bunch of those messages
(and some weirder ones, but let's take it one step at a time).

if you comment out the 'import "C"' line the message will change but
still happen, which makes me think that at least in part this is a Go
issue (or that we're holding it wrong).

Note that the exec does work; the warning seems to come from a
different thread than the one doing the Exec (the other clue that
points in this direction is that sometimes the message is truncated).
You can verify the fact that it does run by changing the /bin/true to
/bin/echo os.Args[1], but because this issue is obviously a race
somewhere, this change makes it less likely to happen (from ~10% down
to ~.5% of runs, in my machines).

One thing that makes this harder to debug is that strace'ing the
process hangs (hard, kill -9 of strace to get out) before reproducing
the issue. This probably means we need to trace it at a lower level,
and I don't know enough about tracing a process group from inside the
kernel to be able to do that; what I can find about kernel-level
tracing is around syscalls or devices.

Ideas?

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft