Cannot Comunicate with Server (MX LINUX 17)

I get this messagene whenever I try to install anything:

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

When I run $systemctl start snapd.service, I get:
Failed to start snapd.service: Unknown unit: snapd.service
See system logs and ‘systemctl status snapd.service’ for. details

$ systemctl status snapd.service
Failed to get properties: No such interface ''

I can confirm that one gets that Failed to get properties error message on MX LINUX 17, at least from the live session.

I think this means the systemd installation is somehow broken; it’s not a snapd issue. From poking around a little it appears that MX LINUX isn’t using systemd as its init, but it doesn’t seem to be properly set up as a surrogate thing either. I don’t know.

As for snapd itself, MX LINUX seems to be based on (antiX, a distro that is based on) debian stretch; the snapd you get is 2.21; the lack of a properly working systemd means that nothing starts the daemon, but if you run it ‘by hand’ (via sudo /usr/lib/snapdsnapd or similar), you get

started snapd/2.21-2+b1 (series 16; classic; devmode) debian/9 (amd64).

again the lack of a working systemd means that you can’t install anything (mount units don’t work).

So, er.

With all kindness and respect,

fix your distro?


You probably ought to check the basics on a distro before you declare it broken–for instance, any of the MX material from website to Users Manual, the DistroWatch page, etc. MX Linux is well known to use SysV as the default init, though users can boot with systemd if they want.

… and if you do this, does snapd work ?

I pointed out how it was broken as shipped, though. Didn’t I? I’ll gladly elaborate if I was unclear.

I don’t know, only booted into systemd during development to test its basic functionality, and wrote this user guide: But stumbling on this thread will give me an incentive now to look more closely.

@chipaca: the distro isn’t broken, it just doesn’t implement systemd by design. It would be broken if it used systemd and then didn’t work.

ubuntu 14.04 (trusty) doesn’t implement systemd by default either, but if systemd is installed (from trusty-updates) it’s properly set up to act as a subordinate; currently MX LINUX has systemd installed by default and systemctl errors out with an obscure message.

I can see your point, though: you want it installed to make switching init easy. I’m afraid I can’t offer a way to achieve that while also not having a broken systemd present when it’s not been used as init.

Unfortunately nobody has done the work to let snapd work without a working systemd, and there is no good way to detect whether it’s properly set up that I know of.

So, one way to “fix” the distro (in the sense that I’d previously described as broken) should be to boot it with systemd. I’ll leave it to you (plural) to figure out if that actually fixes the issue, and if there are changes on the snapd side that we can do to better support this please do let us know.

Thanks, John.

Jesse brought this up in his DistroWatch review as well, so it is
currently on our “MX-18 Brainstorming” list. If we had the money and
manpower of Ubuntu, we would probably have taken this on…


EDIT: actually, we wanted it installed to make certain applications such as Network Manager work, so are using a shim.

I passed this thread to the MX Devs, and one of them reported that he has in fact booted mx in systemd mode and run snaps.

1 Like