/snapcraft

Add document about debugging snaps. #261

Merged
merged 1 commit into from Jan 27, 2016

Conversation

Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@dholbach @kyrofa @sergiusens
@dholbach
Contributor

dholbach commented Jan 26, 2016

LP: #1538016
docs/debug.md
+Further, systemd has log dump facility to look at all system and snap
+services. The "snappy service" command provides a easy way to monitor and
+inspect snap services. To get the status of all snap services run "snappy
+service status". To inspect the the logs run "snappy service logs". Both
@kyrofa

kyrofa Jan 26, 2016

Member

An extra "the" is in there.

docs/debug.md
+In order to test a new snap on a Snappy system you need to install it first.
+This is called sideloading and it can be done via
+`snappy-remote --url=ssh://ubuntu@webdm.local/ install snapname.snap`.
+Alternatively the nap can be copied via scp into the Snappy system and
@kyrofa

kyrofa Jan 26, 2016

Member

s/nap/snap/

docs/debug.md
+service status". To inspect the logs run "snappy service logs". Both commands
+can take a snap name to limit to a specific snap and also `<snapname>` to
+limit to only a specific service of a snap (ie for the shout service in
+`shout.sergiusens` run: `sudo snappy service logs shout`).
@kyrofa

kyrofa Jan 26, 2016

Member

Both commands can take a snap name to limit to a specific snap and also <snapname> to limit to only a specific service of a snap[...]

I don't quite understand what you're saying here. In my testing, there was no way to limit the logs to only a specific service of the .snap-- only sudo snappy service logs <package name>.

ie for the shout service in [...]

Pedantic, but you probably want "e.g." here instead of "i.e.".

@dholbach

dholbach Jan 27, 2016

Contributor

This is on rolling/edge: http://paste.ubuntu.com/14679024/

@kyrofa

kyrofa Jan 27, 2016

Member

Ah, I understand that snappy service logs is a valid command, as is snappy service logs <snapname>. What I mean to say is that the sentence "Both commands can take a snap name to limit to a specific snap and also to limit to only a specific service of a snap" is not clear to me. snappy service logs <snapname> does indeed limit it to services contained in that given snap, but what if that .snap contains three services? It will show the logs for all three jumbled together. There doesn't seem to be a way to get the log for a single service out of it, which "to limit to only a specific service of a snap" implies.

@dholbach

dholbach Jan 27, 2016

Contributor

Ah yes, I see. Let me fix that. :-)

docs/debug.md
+example, the snap `pastebinit.mvo` contains a `pastebinit` script. The binary
+on disk will be called `pastebinit.pastebinit`. The exception of this rule are
+frameworks which may have short binary names. E.g. the docker package contains
+a docker binary.
@kyrofa

kyrofa Jan 26, 2016

Member

Perhaps the framework sentence should be removed considering that frameworks as we know them will not exist in 16.04.

docs/debug.md
+To find out what paths are available to write the `hello-world` package is
+helpful. After installing it the command `hello-world.env` is available that
+will show the environment that the snap binaries see. The
+`SNAP_APP_USER_DATA_PATH` and `SNAP_APP_DATA_PATH` contain the directories
@kyrofa

kyrofa Jan 26, 2016

Member

These are deprecated now.

@dholbach

dholbach Jan 27, 2016

Contributor

Hum, are you commenting on the environment variable names? This is what I see on rolling/edge:

(amd64)ubuntu@localhost:$ hello-world.env | grep SNAP_APP
SNAP_APP_PATH=/apps/hello-world.mvo/2.0
SNAP_APP_USER_DATA_PATH=/home/ubuntu/apps/hello-world.mvo/2.0
SNAP_APP_TMPDIR=/tmp
SNAP_APP_DATA_PATH=/var/lib/apps/hello-world.mvo/2.0
(amd64)ubuntu@localhost:$

@kyrofa

kyrofa Jan 27, 2016

Member

Yeah try grepping for only SNAP. For more information see the PR that added them. The variables are still there, but they've been deprecated and replaced with different names.

docs/debug.md
+log messages (rarely)-- if you feel this is the case, reboot and try again):
+
+ $ sudo snappy install snappy-debug
+ $ sudo snappy-debug.security disable-rate-limiting
@kyrofa

kyrofa Jan 26, 2016

Member

Might be worth pointing out that snappy-debug.security scanlog does this automatically while running.

@dholbach

dholbach Jan 27, 2016

Contributor

What's a bit weird is that I can't run this under sudo, I get:

sudo: snappy-debug.security: command not found

Running this as the ubuntu user, I get

sysctl: permission denied on key 'kernel.printk_ratelimit'

but the other output is fine...

@kyrofa

kyrofa Jan 27, 2016

Member

Oh odd... I can run it as sudo on 15.04 just fine-- I've not tried on rolling.

@dholbach

dholbach Jan 27, 2016

Contributor

You are right about 15.04. Shall we document the behaviour you see and treat rolling as a bug? It looks likely to me. @sergiusens - what do you think?

@kyrofa

kyrofa Jan 27, 2016

Member

That seems reasonable to me.

@kyrofa
Member

kyrofa commented Jan 26, 2016

Excellent document, though some of it is specific to 15.04 (e.g. using deprecated environment variables, etc.).
@sergiusens
Collaborator

sergiusens commented Jan 27, 2016

Thanks @dholbach this is excellent content. I do agree with @kyrofa in that we should use the new env vars.
@sergiusens
Collaborator

sergiusens commented Jan 27, 2016

Aside from my previous comment, here's a preemptive 👍
docs/debug.md
+* Attempting to write to files outside of `SNAP_DATA` and `SNAP_USER_DATA`.
+ This is a very common problem for apps that are being ported to Ubuntu Core
+ or packaged as snaps for the first time. Typical issues might include:
+ * writing to files in the read only `SNAP_DIR`. Fix this by writing
@kyrofa

kyrofa Jan 27, 2016

Member

This one is actually $SNAP.

docs/debug.md
+ This is a very common problem for apps that are being ported to Ubuntu Core
+ or packaged as snaps for the first time. Typical issues might include:
+ * writing to files in the read only `SNAP_DIR`. Fix this by writing
+ to `SNAP_DATA` for `services` and either `SNAP_APP_DATA` or
@kyrofa

kyrofa Jan 27, 2016

Member

I believe there's only $SNAP_DATA and $SNAP_USER_DATA, no $SNAP_APP_DATA.

docs/debug.md
+ or similar
+ * improperly evaluating or typoing `SNAP_` variables so the program
+ uses the wrong path. Eg, using `$SNAP_APP_DATA/foo` instead of
+ `$SNAP_DIR/foo` (`SNAP_APP_DATA` is non-existent so it would
@kyrofa

kyrofa Jan 27, 2016

Member

s/$SNAP_DIR/$SNAP/ . I see a few more below as well.

docs/debug.md
+ * hard coded paths in the program. The program should be adjusted ideally
+ to understand `SNAP_` variables or use relative paths
+* Attempting to read files outside of `SNAP_DIR`, `SNAP_DATA` and
+ `SNAP_USER`. This usually happens if your program is looking for something
@kyrofa

kyrofa Jan 27, 2016

Member

$SNAP_USER_DATA.

docs/debug.md
+
+### Find a binary in the file system hierarchy
+
+All binary names can be found in `/apps/bin/`. The snappy tool will generate
@kyrofa

kyrofa Jan 27, 2016

Member

Ah, another thing in rolling: /apps is now /snaps.

@dholbach
Add document about debugging snaps. 
LP: #1538016

All checks have passed

2 successful checks
continuous-integration/travis-ci/pr — The Travis CI build passed
Details
coverage/coveralls — Coverage remained the same at 91.318%
Details
4f9e610
@sergiusens
Collaborator

sergiusens commented Jan 27, 2016

👍
@sergiusens
Collaborator

sergiusens commented Jan 27, 2016

Thanks for this!

sergiusens added a commit that referenced this pull request Jan 27, 2016

@sergiusens
Merge pull request #261 from dholbach/add-debugging-doc 
Add document about debugging snaps.
fd737d9

@sergiusens sergiusens merged commit fd737d9 into snapcore:master Jan 27, 2016
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 91.318%
Details

@dholbach dholbach deleted the dholbach:add-debugging-doc branch Jan 27, 2016

smoser pushed a commit to smoser/snapcraft that referenced this pull request Sep 14, 2016

@ahmetb
Add more logs to RDMA drivers (#261) 
* Add more logs to default/rdma.py

Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>

* Add more logs to distro/suse/rdma.py
ff2a38b

kalikiana pushed a commit to kalikiana/snapcraft that referenced this pull request Apr 6, 2017

@sergiusens
Merge pull request #261 from dholbach/add-debugging-doc 
Add document about debugging snaps.
48347e6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment