Hello all,
Running on Hashlinux bspwm, Kernel 5.12.14-arch1-1
Installed via yay -S snapd
I already ran sudo systemctl enable --now snapd.socket
When I try to run: sudo snap install hello-world, I always get returned:
error: cannot communicate with server: Post "http://localhost/v2/snaps/hello-world": dial unix /run/snapd.socket: connect: no such file or directory
I already tried:
systemctl start snapd.service
systemctl restart snapd
All to no avail… Here is my systemctl status snapd results:
~ systemctl status snapd ok 16:01:28
○ snapd.service - Snap Daemon
Loaded: loaded (/usr/lib/systemd/system/snapd.service; disabled; vendor preset: disabled)
Active: inactive (dead) since Mon 2021-07-05 15:58:20 PST; 4min 2s ago
TriggeredBy: ● snapd.socket
Process: 48491 ExecStart=/usr/lib/snapd/snapd (code=exited, status=42)
Main PID: 48491 (code=exited, status=42)
CPU: 57ms
Jul 05 15:58:15 hashlinux-a320mh snapd[48491]: patch.go:63: Patching system state level 6 to sublevel 1...
Jul 05 15:58:15 hashlinux-a320mh snapd[48491]: patch.go:63: Patching system state level 6 to sublevel 2...
Jul 05 15:58:15 hashlinux-a320mh snapd[48491]: patch.go:63: Patching system state level 6 to sublevel 3...
Jul 05 15:58:15 hashlinux-a320mh snapd[48491]: daemon.go:248: started snapd/2.51.1-1 (series 16; classic; devmode) hash/I (amd64) linux/5.12.14-arch1-1.
Jul 05 15:58:15 hashlinux-a320mh snapd[48491]: daemon.go:341: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Jul 05 15:58:15 hashlinux-a320mh systemd[1]: Started Snap Daemon.
Jul 05 15:58:20 hashlinux-a320mh snapd[48491]: daemon.go:508: gracefully waiting for running hooks
Jul 05 15:58:20 hashlinux-a320mh snapd[48491]: daemon.go:510: done waiting for running hooks
Jul 05 15:58:20 hashlinux-a320mh snapd[48491]: daemon stop requested to wait for socket activation
Jul 05 15:58:20 hashlinux-a320mh systemd[1]: snapd.service: Deactivated successfully.
Result of snap version
~ snap version 3 err 16:02:22
snap 2.51.1-1
snapd unavailable
series -
Any help provided is highly appreciated
This is expected when no snaps are installed. There were specific requests for snapd to shut down in such scenarios. At this point, as the log states, snapd goes into socket activation mode.
The socket is created by systemd. Make sure that the snapd.socket unit is active and that the socket file is present at /run/snapd.socket.
This is done via this command:
sudo systemctl enable --now snapd.socket
correct?
Hmmm… It seems that the socket file is not present. Any ideas on how to remediate the issue?
You can check the journal looking for errors when creating the socket?
Does Apparmor being disabled have anything to do with this?
It shouldn’t have, do you have a log indicating otherwise?
Posting snippet of the journal here:
If you want I can run a fresh install then re-run the required commands and provide a journal of that as well.
snap install hello-world ok 16:19:25
error: cannot communicate with server: Post "http://localhost/v2/snaps/hello-world": dial unix /run/snapd.socket: connect: no such file or directory
/etc clear 1 err 16:20:01
/etc journalctl -xu snapd.service ok 16:20:04
-- Journal begins at Mon 2021-07-05 15:15:24 PST, ends at Mon 2021-07-05 16:19:30 PST. --
Jul 05 15:18:05 hashlinux-a320mh systemd[1]: Starting Snap Daemon...
░░ Subject: A start job for unit snapd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit snapd.service has begun execution.
░░
░░ The job identifier is 878.
Jul 05 15:18:05 hashlinux-a320mh snapd[1064]: AppArmor status: apparmor not enabled
Jul 05 15:18:05 hashlinux-a320mh snapd[1064]: daemon.go:248: started snapd/2.51.1-1 (series 16; classic; devmode) hash/I (amd64) linux/5.12.14-arch1-1.
Jul 05 15:18:05 hashlinux-a320mh snapd[1064]: daemon.go:341: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Jul 05 15:18:05 hashlinux-a320mh snapd[1064]: helpers.go:105: error trying to compare the snap system key: system-key missing on disk
Jul 05 15:18:05 hashlinux-a320mh systemd[1]: Started Snap Daemon.
░░ Subject: A start job for unit snapd.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit snapd.service has finished successfully.
░░
░░ The job identifier is 878.
Jul 05 15:18:05 hashlinux-a320mh snapd[1064]: stateengine.go:150: state ensure error: no state entry for key
Jul 05 15:18:05 hashlinux-a320mh snapd[1064]: api_snaps.go:299: Installing snap "hello-world" revision unset
Jul 05 15:18:10 hashlinux-a320mh snapd[1064]: daemon.go:508: gracefully waiting for running hooks
Jul 05 15:18:10 hashlinux-a320mh snapd[1064]: daemon.go:510: done waiting for running hooks
Jul 05 15:18:10 hashlinux-a320mh snapd[1064]: daemon stop requested to wait for socket activation
Jul 05 15:18:10 hashlinux-a320mh systemd[1]: snapd.service: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ The unit snapd.service has successfully entered the 'dead' state.
Jul 05 15:21:02 hashlinux-a320mh systemd[1]: Starting Snap Daemon...
░░ Subject: A start job for unit snapd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit snapd.service has begun execution.
░░
░░ The job identifier is 954.
Jul 05 15:21:02 hashlinux-a320mh snapd[2615]: AppArmor status: apparmor not enabled
Jul 05 15:21:02 hashlinux-a320mh snapd[2615]: daemon.go:248: started snapd/2.51.1-1 (series 16; classic; devmode) hash/I (amd64) linux/5.12.14-arch1-1.
Jul 05 15:21:02 hashlinux-a320mh snapd[2615]: daemon.go:341: adjusting startup timeout by 30s (pessimistic estimate of 30s plus 5s per snap)
Jul 05 15:21:02 hashlinux-a320mh systemd[1]: Started Snap Daemon.
░░ Subject: A start job for unit snapd.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
I think I’m quite confused now. Is the snapd service active? Is the socket file present (/run/snapd.socket)? Is the socket unit active?
Since this looks like some random distro, can you post the contents of /etc/os-release as well?
Hello sure, I’ll be posting it here a few hours from now. I just left my pc and am at my phone atm. I’ll add the details here as soon as I get back home. Thanks
To answer your query:
Is snapd service active?
I ran the command to start the snapd service and it still yields the same result (the error outlined in the post.)
Is the socket file present?
It is not present
Is the socket unit active?
It becomes active for a few seconds (around 5 secs) then dies.
I will provide the /etc/os-release/ here when I get home but I am using hashlinux with bspwm as the window manager
Btw, here’s the os-release file
NAME=Hash
PRETTY_NAME="Hash Linux"
ID=hash
ID_LIKE="hash"
VERSION_ID=I
ANSI_COLOR="0;36"
HOME_URL="https://hashproject.org"
SUPPORT_URL="https://hashproject.org"
FWIW, snapd does not know about this distro and IIRC it assumes that snaps are at /snap. Since it’s not arch, I don’t quite understand why you are using AUR and arch packages. The AUR snapd package is configured to use /var/lib/snapd/snap.
I think that first you need to figure out why systemd does not create the socket file. Is it present after reboot? Is there anything in system journal (not the snapd unit journal) that explains why it’s not being created?
Here’s my journalctl -xe
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=54 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=53 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=52 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=55 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=57 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=56 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=58 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=59 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=60 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=61 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=62 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=63 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=64 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=65 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=66 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=67 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=68 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=69 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=70 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh systemd[1]: Reloading.
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=60 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=59 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=58 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=63 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=62 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=61 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=64 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=67 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=66 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=65 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=68 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=70 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=69 op=UNLOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=71 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=72 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=73 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=74 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=75 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=76 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=77 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=78 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=79 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=80 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=81 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=82 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh audit: BPF prog-id=83 op=LOAD
Jul 06 17:41:54 hashlinux-a320mh snapd[4328]: taskrunner.go:271: [change 11 "Mount snap \"core\" (11316)" task] failed: [start snap-core-11316.mount] failed with exit status 1: Job failed. See "journalctl -xe" for details.
Jul 06 17:41:54 hashlinux-a320mh snapd[4328]: handlers.go:511: Reported install problem for "core" as already-reported
Sorry, but there’s nothing useful in the journal. Can you check whether the kernel even supports squashfs? grep squashfs /proc/filesystems should confirm that. Maybe you need to load a module (eg. modprobe squashfs) ?
Hello, I’ve reinstalled snap. The good news is… Snap daemon is running. The bad news is:
~ snap install hello-world ok 17:41:27
error: cannot perform the following tasks:
- Mount snap "core" (11316) ([start snap-core-11316.mount] failed with exit status 1: Job failed. See "journalctl -xe" for details.
It seems that I did a corrupted install which led to the previous issue.
I’ve tried reading other forum posts regarding the Mount snap "core" issue. Still haven’t figure this part out yet.
I ran the command, it returns squashfs & I am running on arch. Kernel 5.12.14-arch1-1 so this is Arch.
grep squashfs /proc/filesystems
squashfs
