Unknown syscall when running an 18.04 built snap

I’ve built kdenlive successfully in an artisinal, bespoke lxc container running Ubuntu 18.04 and with the KDE Neon user/lts repo added to get all that lovely KDE and Qt freshness.

The snapcraft.yaml looks like http://paste.ubuntu.com/p/BG6fJhYrz5/

This successfully builds a snap based on base: core18 (which I appreciate is unstable).

I can install and run the snap in devmode on my 18.04 laptop, but when installed as a strict snap I get this with snappy-debug.security scanlog

= Seccomp =
Time: Aug 29 18:27:14
Log: auid=1000 uid=1000 gid=1000 ses=4 pid=25457 comm="kdenlive" exe="/snap/kdenlive-devel/x2/usr/bin/kdenlive" sig=0 arch=c000003e 332(UNKNOWN) compat=0 ip=0x7fb389b00839 code=0x50000
Syscall: UNKNOWN

Here’s the full strace in case it’s useful. http://paste.ubuntu.com/p/9gjt2GDmQW/

I had a chat with @jdstrand about it and he suspected the unknown syscall might be to do with some libc mismatch. Perhaps @sergiusens (or indeed anyone) has an idea?

Can you put the snap somewhere?

Also, is this buildable without enabling the kde neon repos?

https://people.canonical.com/~alan/kdenlive-devel_18.08.0_amd64.snap - here’s the snap.

I could try building without the neon repo, sure.

Ok, made a little progress. I rebuilt the snap without the kde neon repo and got a more successful build.


So I guess I was pulling in something erroneous from the neon repo, which I’m now not. Now I get a dialog asking for mlt profiles and after that it crashes. Need more work on this.

= AppArmor =                                                  
Time: Aug 30 13:14:38
Log: apparmor="DENIED" operation="open" profile="snap.kdenlive-devel.kdenlive-devel" name="/proc/sys/kernel/core_pattern" pid=9958 comm="kdenlive" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /proc/sys/kernel/core_pattern (read)
* adjust program to not access '@{PROC}/sys/kernel/core_pattern'                                                                                                                              
= AppArmor =
Time: Aug 30 13:14:39                                  
Log: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/a11y/bus" interface="org.freedesktop.DBus.Properties" member="Get" mask="send" name="org.a11y.Bus" pid=9958 label="snap.kdenliv
e-devel.kdenlive-devel" peer_pid=9480 peer_label="unconfined"
DBus access 

and still works with devmode?

Sadly not. It dies after asking about mlt profiles.

This is likely it trying to handle itself crashing.

This rule is missing from desktop-legacy:

dbus (send)

(there are another Get rule, but it doesn’t match the above). I’ll add that to the next batch of updates.

Back to the unknown syscall when running a Qt app pakcaged with Qt 5.11 from Neon. Having the same issue with VLC built with core18, using Neon repos.

syscall 332 seems to be statx.

= Seccomp =
Time: Sep 12 19:43:59
Log: auid=1000 uid=1000 gid=1000 ses=3 pid=2441 comm=“vlc-qt-check” exe="/snap/vlc/x1/usr/libexec/vlc/vlc-qt-check" sig=0 arch=c000003e 332(UNKNOWN) compat=0 ip=0x7f1f685ee839 code=0x50000
Syscall: UNKNOWN

= Seccomp =
Time: Sep 12 19:43:59
Log: auid=1000 uid=1000 gid=1000 ses=3 pid=2452 comm=“vlc-qt-check” exe="/snap/vlc/x1/usr/libexec/vlc/vlc-qt-check" sig=0 arch=c000003e 332(UNKNOWN) compat=0 ip=0x7f4cb646d839 code=0x50000
Syscall: UNKNOWN

The failure to launch that check prevents VLC from launching a Qt interface (which will likely fail the same way since statx is used internally in Qt).

The snap with that Qt is available under http://thre.sh/stuff/vlc_4.0.0-dev-4642-g53946e4ed9_amd64.snap, sha512 is 5126d185fe2e9188263cf57c13319ac7dd82dd99b4f63b2b8ad064d499d1f23d2756cfa3a1339c8b0f565a029c424460c02324cb1fdb9eff8e9084cea756151f stuff/vlc_4.0.0-dev-4642-g53946e4ed9_amd64.snap

It looks like this was merged last week: https://github.com/snapcore/snapd/pull/5918