Simplenote snap - cannot stat /var/lib/snapd/seccomp/bpf: No such file or directory

dpb@helo:~[]$ simplenote
cannot stat /var/lib/snapd/seccomp/bpf: No such file or directory

Note, this takes about 2-3 minutes to actually timeout and error.

dpb@helo:~[]$ snap version
snap    2.26.14
snapd   2.25
series  16
ubuntu  16.04
kernel  4.4.0-79-generic
dpb@helo:~[]$ snap list
Name                   Version     Rev   Developer         Notes
canonical-livepatch    7           22    canonical         -
conjure-up             2.2.2       561   canonical         classic
core                   16-2.26.14  2462  canonical         -
documentation-builder  1.4.3       34    canonicalwebteam  -
git-ubuntu             0           101   nacc              classic
htop                   2.0.2       68    maxiberta         -
simplenote             1.0.8       2     snapcrafters      -
telegram-latest        1.0.5       4     pain7             -
ubuntu-image           1.1+snap3   73    canonical         classic

Any ideas?

Thank you for reporting the issue.

At first sight the discrepancy between snap and snapd versions feels like a potential issue.

Can you paste some more data? env | grep SNAP_ please

Yup! Here:

I see this in your logs Jul 26 08:52:27 helo /usr/lib/snapd/snapd[17216]: cmd.go:59: DEBUG: re-exec disabled by user, did you set SNAP_REEXEC=0 in your environment by any chance? What is your version of snapd the debian package (apt-cache policy snapd)?

Right now, I’m here: but I’m doing an apt-get dist-upgrade right now as I have some stale packages on the system. And no, I don’t know of any SNAP_REEXEC=0, but let me check through the usual places. It doesn’t sounds like something I would have set. :slight_smile:

dpb@helo:~[]$ apt-cache policy snapd
  Installed: 2.25
  Candidate: 2.25
  Version table:
 *** 2.25 500
        500 xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.0.2 500
        500 xenial/main amd64 Packages

Oh, interesting. We don’t test updated from 2.0.2 to stable snap. I’ll try to update our test suite to do that too.

This is interesting because we fixed one of the bugs exactly like this and this is why we made 2.26.14 release after the .13 one

Oh interesting. So, I’m fully up to date on 16.04 now, and I even rebooted for good measure, and I’m still getting the same issue. Something else I can try?

Oh, that’s more interesting (in a bad way) than before.

Can you attach your journalctl -u snapd output with the new snapd around? And please add snap version again if you can.

Thanks for looking zyga,

dpb@helo:ubuntu-advantage-script[(master)]$ journalctl -u snapd | pastebinit
dpb@helo:ubuntu-advantage-script[(master)]$ snap version
snap    2.26.14
snapd   2.25
series  16
ubuntu  16.04
kernel  4.4.0-87-generic

I’m guessing this is the problem?

Jul 26 16:31:40 helo /usr/lib/snapd/snapd[3561]: helpers.go:206: cannot connect plug "network-bind" from snap "core", no such plug

No, the message is a red herring. It’s harmless.

This is the real problem: Jul 26 16:31:39 helo /usr/lib/snapd/snapd[3561]: cmd.go:59: DEBUG: re-exec disabled by user

I think that if you systemctl restart snapd.service your problem will go away. Can you give that a try?

Still getting that re-exec disabled by user after issuing the systemctl restart snapd.service.

with sudo ps -efx I can see this:

 2170 ?        Ssl    0:00 /usr/lib/snapd/snapd LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games LISTEN_PID=2170 LISTEN_FDS=2 LISTEN_FDNAMES=snapd.socket:snapd.socket SNAP_REEXEC=0

ANNND, that worked. /etc/systemd/system/snapd.service.d/override.conf contained the smoking gun (SNAP_REEXEC=0).

Removing that line fixed things.

My guess is that was there from some debugging that I was doing, not sure.


1 Like