SNAPS Not always starting - OpenSuSE Leap 15.2 Beta

I found that sometimes after a computer restart at the first login that SNAP applications all don’t start. After a logout and login again they usually run.

I am trying something which so far appears to have fixed this:

From terminal, add a sudoers.d file and allow user to restart snapd.service like this:

>  /etc/sudoers.d/snap
echo "%users ALL = NOPASSWD:/bin/systemctl restart snapd.service" >> /etc/sudoers.d/snap

And my distro has /etc/profile.d/desktop-data.sh ( be CAREFUL what you put in this file, loops can hold a black screen login open indefinitely)

Put this in /etc/profile.d/desktop-data.sh so it runs at every login:

sudo systemctl restart snapd.service

When I find out what is actually causing this - maybe something in Display Manager cache or something I will advise if there is a more effective method of dealing with it.

Could you try to obtain the journalctl -b log and the output of findmnt --list from when the snaps fail to start?

Sure, I will remove the interim “fix” and do this next time it happens.

It happened again and I have output journalctl -b and findmnt --list.

journalctl -b is way too big too paste here unless you really want to over 2000 lines - do you have an email address I can send the txt file to you ?

Here is the contents of findmnt --list:

TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
/proc proc proc rw,nosuid,nodev,noexec,relatime
/dev devtmpfs devtmpfs rw,nosuid,size=4026304k,nr_inodes=1006576,mode=755
/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
/dev/shm tmpfs tmpfs rw,nosuid,nodev
/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
/run tmpfs tmpfs rw,nosuid,nodev,mode=755
/sys/fs/cgroup tmpfs tmpfs ro,nosuid,nodev,noexec,mode=755
/sys/fs/cgroup/unified cgroup cgroup2 rw,nosuid,nodev,noexec,relatime
/sys/fs/cgroup/systemd cgroup cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd
/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
/sys/fs/cgroup/memory cgroup cgroup rw,nosuid,nodev,noexec,relatime,memory
/sys/fs/cgroup/perf_event cgroup cgroup rw,nosuid,nodev,noexec,relatime,perf_event
/sys/fs/cgroup/hugetlb cgroup cgroup rw,nosuid,nodev,noexec,relatime,hugetlb
/sys/fs/cgroup/rdma cgroup cgroup rw,nosuid,nodev,noexec,relatime,rdma
/sys/fs/cgroup/freezer cgroup cgroup rw,nosuid,nodev,noexec,relatime,freezer
/sys/fs/cgroup/net_cls,net_prio cgroup cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio
/sys/fs/cgroup/cpu,cpuacct cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct
/sys/fs/cgroup/devices cgroup cgroup rw,nosuid,nodev,noexec,relatime,devices
/sys/fs/cgroup/cpuset cgroup cgroup rw,nosuid,nodev,noexec,relatime,cpuset
/sys/fs/cgroup/blkio cgroup cgroup rw,nosuid,nodev,noexec,relatime,blkio
/sys/fs/cgroup/pids cgroup cgroup rw,nosuid,nodev,noexec,relatime,pids
/ /dev/mapper/system-root[/@] btrfs rw,relatime,space_cache,subvolid=256,subvol=/@
/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=16687
/dev/mqueue mqueue mqueue rw,relatime
/dev/hugepages hugetlbfs hugetlbfs rw,relatime,pagesize=2M
/sys/kernel/debug debugfs debugfs rw,relatime
/boot/grub2/x86_64-efi /dev/mapper/system-root[/@/boot/grub2/x86_64-efi] btrfs rw,relatime,space_cache,subvolid=264,subvol=/@/boot/grub2/x86_64-efi
/tmp /dev/mapper/system-root[/@/tmp] btrfs rw,relatime,space_cache,subvolid=260,subvol=/@/tmp
/opt /dev/mapper/system-root[/@/opt] btrfs rw,relatime,space_cache,subvolid=263,subvol=/@/opt
/srv /dev/mapper/system-root[/@/srv] btrfs rw,relatime,space_cache,subvolid=261,subvol=/@/srv
/boot/grub2/i386-pc /dev/mapper/system-root[/@/boot/grub2/i386-pc] btrfs rw,relatime,space_cache,subvolid=265,subvol=/@/boot/grub2/i386-pc
/var /dev/mapper/system-root[/@/var] btrfs rw,relatime,space_cache,subvolid=258,subvol=/@/var
/usr/local /dev/mapper/system-root[/@/usr/local] btrfs rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local
/root /dev/mapper/system-root[/@/root] btrfs rw,relatime,space_cache,subvolid=262,subvol=/@/root
/snap/gtk2-common-themes/9 /dev/loop4 squashfs ro,nodev,relatime
/snap/vlc/1397 /dev/loop2 squashfs ro,nodev,relatime
/snap/blender/36 /dev/loop5 squashfs ro,nodev,relatime
/snap/chromium/1040 /dev/loop0 squashfs ro,nodev,relatime
/snap/obs-studio/888 /dev/loop3 squashfs ro,nodev,relatime
/snap/kdenlive/22 /dev/loop7 squashfs ro,nodev,relatime
/snap/dataexplore/11 /dev/loop6 squashfs ro,nodev,relatime
/snap/gtk-common-themes/1440 /dev/loop1 squashfs ro,nodev,relatime
/snap/telegram-desktop/1038 /dev/loop8 squashfs ro,nodev,relatime
/snap/audacity/599 /dev/loop11 squashfs ro,nodev,relatime
/snap/core18/1668 /dev/loop10 squashfs ro,nodev,relatime
/snap/core/8689 /dev/loop14 squashfs ro,nodev,relatime
/snap/gnome-3-28-1804/116 /dev/loop13 squashfs ro,nodev,relatime
/snap/firefox/323 /dev/loop15 squashfs ro,nodev,relatime
/snap/kde-frameworks-5-core18/32 /dev/loop18 squashfs ro,nodev,relatime
/snap/atom/247 /dev/loop9 squashfs ro,nodev,relatime
/snap/chromium/1043 /dev/loop16 squashfs ro,nodev,relatime
/snap/atom/248 /dev/loop12 squashfs ro,nodev,relatime
/snap/chromium-ffmpeg/15 /dev/loop17 squashfs ro,nodev,relatime
/home /dev/mapper/system-home xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota
/sys/kernel/debug/tracing tracefs tracefs rw,relatime
/run/user/1000 tmpfs tmpfs rw,nosuid,nodev,relatime,size=807600k,mode=700,uid=1000,gid=100
/sys/fs/fuse/connections fusectl fusectl rw,relatime
/run/user/1000/doc /dev/fuse fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=100
/run/snapd/ns tmpfs[/snapd/ns] tmpfs rw,nosuid,nodev,mode=755
/run/snapd/ns/firefox.mnt nsfs[mnt:[4026532668]] nsfs rw

A pastebin is fine. fpaste.org, paste.ubuntu.com or somesuch.

It seems that snaps aren’t mounted in your system for some reason. This is weird, because the units are set up to be required by multi-user.target, which should be normally reached before your display manager runs. OTOH, looking and findmnt output, snap mounts are present. Is there a specific snap that does not work?

Can you run systemctl list-dependencies multi-user.target and make sure that snap-.*.mount units are listed there?

When this happens, can you check systemctl status of the snap mount unit that does not work for you? The output of systemctl status snap-<snapname>\*.mount would be useful here.

It’s all SNAPS when it occurs.

Next failure I will systemctl status snap-<snapname>\*.mount

From systemctl list-dependencies multi-user.target:

● ├─snap-atom-247.mount
● ├─snap-atom-248.mount
● ├─snap-audacity-599.mount
● ├─snap-blender-36.mount
● ├─snap-blender-37.mount
● ├─snap-chromium-1040.mount
● ├─snap-chromium-1043.mount
● ├─snap-chromium\x2dffmpeg-15.mount
● ├─snap-core-8689.mount
● ├─snap-core18-1668.mount
● ├─snap-dataexplore-11.mount
● ├─snap-firefox-323.mount
● ├─snap-firefox-330.mount
● ├─snap-gnome\x2d3\x2d28\x2d1804-116.mount
● ├─snap-gtk2\x2dcommon\x2dthemes-9.mount
● ├─snap-gtk\x2dcommon\x2dthemes-1440.mount
● ├─snap-kde\x2dframeworks\x2d5\x2dcore18-32.mount
● ├─snap-kdenlive-22.mount
● ├─snap-obs\x2dstudio-888.mount
● ├─snap-telegram\x2ddesktop-1038.mount
● ├─snap-vlc-1397.mount

snapnew

This is confusing. The units are active and mounted. Did it still not work?

SNAPS did not work. As I have a sudoers entry for the user to restart the service, and as I have described above I was before this testing phase you iniitiated calling systemctl restart snapd.service from /etc/profile.d/desktop-data.sh. So I ran that from the command line and SNAPS still did not start. So I logged out and back in and SNAPS started.

So it may have nothing at all to do with restarting the service using systemctl restart snapd.service, nor the entry for that in /etc/profile.d/desktop-data.sh. However having that entry in /etc/profile.d/desktop-data.sh may have been adding just enough milli/microseconds latency before Plasma started to make SNAPS work. I’m now thinking it’s looking like something going on between mounting of /home/$USER and sddm starting Plasma as opposed to a SNAP issue.

Apologies I realise I neglected to include this only occurs intermittently at first user login after reboot.