snap doesnt work. error: cannot communicate with server

Bug #1631514 reported by eduardo on 2016-10-07
48
This bug affects 11 people
Affects Status Importance Assigned to Milestone
snapd
Undecided
Unassigned
snapd (Ubuntu)
Undecided
Unassigned

Bug Description

Hello, on Manjaro KDE I cant do anything related to snap because this message always appear:

"error: cannot communicate with server: Post http://localhost/v2/login: dial unix /run/snapd-snap.socket: connect: no such file or directory"

The output is different to what I have seen here on launchpad, so I created a new thread.

Michael Vogt (mvo) wrote :

Could you please attach the output of:
$ systemctl status snapd.service
to this bug?

Changed in snapd (Ubuntu):
status: New → Incomplete
Yung Shen (kaxing) wrote :

happen to see the same error message on 16.04.1,

snapd v2.20.1ubuntu1
ubuntu-core v16.04.1 rev1357

systemctl status snapd.service
● snapd.service - Snappy daemon
   Loaded: loaded (/lib/systemd/system/snapd.service; disabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2017-01-09 09:37:53 CST; 8min ago
 Main PID: 2149 (code=exited, status=0/SUCCESS)

Jan 06 11:24:00 X230 /usr/lib/snapd/snapd[2149]: daemon.go:174: DEBUG: uid=0;@ POST /v2/snaps 26.478524ms 500
Jan 07 03:43:54 X230 /usr/lib/snapd/snapd[2149]: daemon.go:174: DEBUG: uid=0;@ POST /v2/snaps 51.193286ms 500
Jan 09 09:30:16 X230 /usr/lib/snapd/snapd[2149]: daemon.go:174: DEBUG: uid=0;@ POST /v2/snaps 18.417449ms 500
Jan 09 09:37:21 X230 /usr/lib/snapd/snapd[2149]: daemon.go:174: DEBUG: uid=0;@ GET /v2/snaps 37.008379ms 200
Jan 09 09:37:25 X230 /usr/lib/snapd/snapd[2149]: daemon.go:174: DEBUG: uid=1000;@ GET /v2/snaps 4.549011ms 200
Jan 09 09:37:29 X230 /usr/lib/snapd/snapd[2149]: daemon.go:174: DEBUG: uid=1000;@ GET /v2/interfaces 4.250357ms 200
Jan 09 09:37:53 X230 systemd[1]: Stopping Snappy daemon...
Jan 09 09:37:53 X230 /usr/lib/snapd/snapd[2149]: main.go:67: Exiting on terminated signal.
Jan 09 09:37:53 X230 snapd[2149]: 2017/01/09 09:37:53.585542 main.go:67: Exiting on terminated signal.
Jan 09 09:37:53 X230 systemd[1]: Stopped Snappy daemon.

-

and restart the snapd service helps:

$ sudo systemctl restart snapd.service
$ systemctl status snapd.service
● snapd.service - Snappy daemon
   Loaded: loaded (/lib/systemd/system/snapd.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-01-09 09:46:56 CST; 1s ago
 Main PID: 9992 (snapd)
    Tasks: 7
   Memory: 22.9M
      CPU: 34ms
   CGroup: /system.slice/snapd.service
           └─9992 /usr/lib/snapd/snapd

Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "network-bind" from snap "wifi-ap", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "network-bind" from snap "rocketchat-server", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "network-bind" from snap "snapweb", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "x11" from snap "tensorflow-demo", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "network-bind" from snap "notes", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "snapd-control" from snap "snapweb", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "unity7" from snap "notes", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "network-bind" from snap "tensorflow-demo", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: helpers.go:102: cannot connect plug "network" from snap "wifi-ap", no such plug
Jan 09 09:46:56 X230 /usr/lib/snapd/snapd[9992]: daemon.go:207: DEBUG: init done in 1.374045ms

Michael Vogt (mvo) wrote :

@Yung Shen: that is interessting - could you please also attach /var/log/apt/history.log and /var/log/apt/term.log ? I wonder if we can find a clue there. It looks like your snapd was not (re)started on upgrade. What if you reboot? Do you need to manually start it then as well?

Yung Shen (kaxing) wrote :

@mvo reboot few times, doesn't seems to see this again.

manually downgrade to 2.0.2 and then re-upgrade to 2.20.1ubuntu1 will not able to reproduce this problem.

Michael Vogt (mvo) wrote :

Looking at your upgrade log I see:
"""
...
Setting up snapd (2.20.1ubuntu1) ...
snapd.service is a disabled or a static unit, not starting it.
...
"""
so it appears for some reason the dpkg systemd helper is confused. Is that reproducable for you for upgrades from 2.17.1ubuntu1 to 2.20.1ubuntu1 ?

Yung Shen (kaxing) wrote :

Manually install snapd_2.17.1_amd64.deb then upgrade to 2.20.1ubuntu1 cannot reproduce this.

snapd ran properly:
Jan 12 12:09:02 X230 /usr/lib/snapd/snapd[11593]: daemon.go:207: DEBUG: init done in 831.812µs
Jan 12 12:09:11 X230 /usr/lib/snapd/snapd[11593]: daemon.go:172: DEBUG: uid=0;@ POST /v2/snaps 9.05233594s 202
Jan 12 12:09:29 X230 /usr/lib/snapd/snapd[11593]: daemon.go:172: DEBUG: uid=1000;@ GET /v2/snaps 7.988072ms 200
Jan 12 12:09:32 X230 /usr/lib/snapd/snapd[11593]: daemon.go:172: DEBUG: uid=1000;@ GET /v2/interfaces 2.114854ms 200

But still seeing 'not starting it' in log messages:
Log started: 2017-01-12 12:08:55
Warning: Stopping snapd.service, but it can still be activated by:
  snapd.socket
Unpacking snapd (2.20.1ubuntu1) over (2.17.1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up snapd (2.20.1ubuntu1) ...
Installing new version of config file /etc/X11/Xsession.d/65snappy ...
snapd.service is a disabled or a static unit, not starting it.
Log ended: 2017-01-12 12:09:03

mark (tiberopoulos) wrote :

I had the same problem on Suse leap 42.2:

# systemctl status snapd
● snapd.service - Snappy daemon
   Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Fri 2017-02-24 09:07:44 GMT; 4s ago
  Process: 2246 ExecStart=/usr/lib/snapd/snapd (code=exited, status=1/FAILURE)
 Main PID: 2246 (code=exited, status=1/FAILURE)

Feb 24 09:07:44 kitchen systemd[1]: snapd.service: Unit entered failed state.
Feb 24 09:07:44 kitchen systemd[1]: snapd.service: Failed with result 'exit-code'.
Feb 24 09:07:44 kitchen systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
Feb 24 09:07:44 kitchen systemd[1]: Stopped Snappy daemon.
Feb 24 09:07:44 kitchen systemd[1]: snapd.service: Start request repeated too quickly.
Feb 24 09:07:44 kitchen systemd[1]: Failed to start Snappy daemon.
Feb 24 09:07:44 kitchen systemd[1]: snapd.service: Unit entered failed state.
Feb 24 09:07:44 kitchen systemd[1]: snapd.service: Failed with result 'start-limit'.

journalctl revealed:
snapd[20747]: error: fatal: directory "/var/lib/snapd" must be present

so I just did # mkdir /var/lib/snapd

and it worked ?!
Did someone forget to make /var/lib/snapd in the install package?

All good. Tks

Joseph Borg (joeborg) wrote :

I also get this issue with Snapd, but without all the errors in the snapd log:

$ systemctl status snapd.service
● snapd.service - Snappy daemon
   Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2017-03-16 17:07:19 UTC; 53s ago
 Main PID: 1530 (snapd)
   CGroup: /system.slice/snapd.service
           └─1530 /usr/lib/snapd/snapd

$ snap login
Email address: <email address hidden>
Password of "<email address hidden>":
error: cannot communicate with server: Post http://localhost/v2/login: EOF

$ snap install nextcloud
error: cannot communicate with server: Post http://localhost/v2/snaps/nextcloud: EOF

etc.

John Lenton (chipaca) wrote :

@Joseph, that looks like a different issue; could you file a new bug? Include the output of “journalctl -u snapd.service” when you do. Thank you!

misha (ashoa) wrote :

got the same error from this command:
sudo snap install --edge --devmode anbox

misha (ashoa) wrote :

● snapd.service - Snappy daemon
   Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
   Active: inactive (dead) (Result: exit-code) since пт 2017-04-21 20:02:12 EEST; 41min ago
  Process: 829 ExecStart=/usr/lib/snapd/snapd (code=exited, status=1/FAILURE)
 Main PID: 829 (code=exited, status=1/FAILURE)

кві 21 20:02:12 misha-boh systemd[1]: snapd.service: Main process exited, code=exited, status=1/FAILURE
кві 21 20:02:12 misha-boh systemd[1]: snapd.service: Unit entered failed state.
кві 21 20:02:12 misha-boh systemd[1]: snapd.service: Failed with result 'exit-code'.
кві 21 20:02:12 misha-boh systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
кві 21 20:02:12 misha-boh systemd[1]: Stopped Snappy daemon.
кві 21 20:02:12 misha-boh systemd[1]: snapd.service: Start request repeated too quickly.
кві 21 20:02:12 misha-boh systemd[1]: Failed to start Snappy daemon.

Joshua Robison (hoshi411) wrote :

I get the same exact error also on Manjaro KDE

# snap install inkscape
error: cannot communicate with server: Post http://localhost/v2/snaps/inkscape: dial unix /run/snapd.socket: connect: no such file or directory

Running in a chroot, so I don't have systemctl available. Fixed this by manually running /usr/lib/snapd/snapd.

Launchpad Janitor (janitor) wrote :

[Expired for snapd (Ubuntu) because there has been no activity for 60 days.]

Changed in snapd (Ubuntu):
status: Incomplete → Expired
Bradley Jelinek (nullu0) wrote :

same thing with manjaro 17.1 Xfce

systemctl restart snapd.service

fixed it

yongle sun (cattei) wrote :

I got the same problem,Windows 10 subsystem Ubuntu server 18 and docker run ubuntu server 16, both get same problem.

Lanskie Lance (plgnply) wrote :

was a about to file a bug regarding this.

error: cannot communicate with server: Post http://localhost/v2/login: dial unix /run/snapd.socket: connect: no such file or directory

and I just followed @Bradley Jelinek then it fixed. Thanks!

I got the same error in Ubuntu 18.04 updated from Ubuntu 16.04.

I tried:
    sudo systemctl restart snapd.service
And I got:
    Job for snapd.service failed because the control process exited with error code.
    See "systemctl status snapd.service" and "journalctl -xe" for details.

I tried:
    sudo apt-get remove snapd
    sudo apt-get install snapd
And I got:
    snapd.snap-repair.service is a disabled or a static unit, not starting it.
    Job for snapd.service failed because the control process exited with error code.
    See "systemctl status snapd.service" and "journalctl -xe" for details.
    Job for snapd.seeded.service failed because the control process exited with error code.
    See "systemctl status snapd.seeded.service" and "journalctl -xe" for details.
    A processar 'triggers' para man-db (2.8.3-2) ...

I tried again with:
    sudo apt purge snapd (instead of just remove)
    reboot
    sudo apt install snapd
As the final message was:
"snapd.snap-repair.service is a disabled or a static unit, not starting it"
I did:
    sudo systemctl start snapd.service
And it worked!

fabrixx (fabrixx) wrote :

systemctl start snapd.service

work for me

Michael Vogt (mvo) on 2018-11-14
Changed in snapd:
status: New → Incomplete
Panagiotis Tabakis (tabakisp) wrote :

@Gustavo It worked for me. It also purged plasma-discover-snap-backend along with snapd. After the purge I performed a autoremove and a clean, following a reboot. On login I installed them again and had the exact same error message. Starting the service manually, snapd can search and install.

Timo Jyrinki (timo-jyrinki) wrote :

Just bumped into this on freshly installed openSUSE Tumbleweed after installing snapd. Rebooting did not help, but systemctl restart snapd.service manually did help.

Timo Jyrinki (timo-jyrinki) wrote :

Reproduce steps:
1. Install openSUSE 15.0
2. Online upgrade to Tumbleweed https://en.opensuse.org/openSUSE:Tumbleweed_upgrade
3. Install snapd from https://software.opensuse.org/package/snapd -> Tumbleweed -> Show experimental packages -> 1 Click install
4. Reboot (if wanted)
5. Observe

Changed in snapd:
status: Incomplete → Confirmed
Zygmunt Krynicki (zyga) wrote :

Hello

On openSUSE the socket and other services are not started automatically. You must install snapd and enable the socket yourself. Services are managed with systemd presets that are in turn managed centrally for the whole distribution.

Timo Jyrinki (timo-jyrinki) wrote :

I've tried disabling and enabling the snapd.service itself, but I still need to restart manually after a reboot.

Additionally as an unrelated thing I also need to run the following after each reboot now:
sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*

Without that I get the same problem as here, from where I got the workaround too:
https://www.reddit.com/r/SolusProject/comments/8j2tpv/problem_with_running_snaps/

With those two I seem to have a nice snap experience now.

Timo Jyrinki (timo-jyrinki) wrote :

Just noting that at least with the latest snapd update I noticed there was a helpful message:

"On a Tumbleweed system you need to run: systemctl enable snapd.apparmor.service"

Ie, not only snapd service itself. With that bit, everything's working as intended!

Maybe this is as far as it can go on openSUSE, although of course fully automated enabling of snapd.service and snapd.apparmor.service would be preferred.

Per (perguth) wrote :

I experienced that problem with a fresh installation of Ubuntu Core for RasbperryPI 3 using the official instructions: https://www.ubuntu.com/download/iot/raspberry-pi-2-3

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers