moved flatpak.env, restarted system and it doesn’t appear to have changed
$ echo $XDG_DATA_DIRS
/home/xxxx/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
And realized I missed some of what you put in you last post regarding x11, follows
Perhaps not a Flatpak issue then. But then please use systemctl --user show-environment instead of echo $XDG_DATA_DIRS . See below.
Reading your posts again, I am a little bit lost because symptoms keep changing. In your first post $PATH is correctly set, at least in the shell:
Then you reinstalled CentOS 8 and different problems appeared. Yet $XDG_DATA_DIRS is correctly set, at least in the shell:
Then /var/lib/snapd/desktop is missing from $XDG_DATA_DIRS but this time from systemctl --user show-environment:
Environment variables might be different in a shell environment and in the graphical session environment. That’s why you should use systemctl --user show-environment.
Perhaps you can do the same on your CentOS machine to recap the problem at hand? With and without /usr/share/gdm/env.d/flatpak.env and always after a reboot to be on the safe side?
There are indeed differences between the values of $PATH in the shell and through systemd (command systemctl). I don’t see these differences in Ubuntu 20.04 and Fedora 31. I don’t know enough to tell whether this is expected or wrong. In any case these discrepancies may well account for the differences you experience between Fedora and CentOS 8.
$PATH indeed lacks /var/lib/snapd/snap/bin outside the shell. That may explain the issues you experience. In any case it explains why you can launch authy from the command line only - but not why you need symlinks.
On the other hand $XDG_DATA_DIRS looks fine now with /var/lib/snapd/desktop always appended. Wasn’t it missing at some point? Anyway, because /var/lib/snapd/desktop is in $XDG_DATA_DIRS you shouldn’t need the symlinks:
I am at a loss why you would need these symlinks. What happens when you remove the symlinks and start authy from the command line?
I cannot yet explain why $XDG_DATA_DIRS is appended /var/lib/snapd/desktop but $PATH is not appended var/lib/snapd/snap/bin since they both seem to be set by /usr/lib/environment.d/990-snapd.conf. Perhaps there are other files involved…
I suspect item 4 is the core issue. At this point installing a CentOS 8 virtual machine seems the only option to get to the bottom of this…
Is there some way I can just update these paths so this will work? The move of flatpak.env seems to have broken flatpak behavior as well, now. I can still launch apps from command line and they show under flatpak list as still installed. I’ve tried --reinstall and remove/reinstall from gui and still apps do not show in application launcher?
Removed (bye bye dependencies) and rolledback flatpak, this restored all the flatpak installs and put me back to state before I removed flatpak. Removed snapd and reinstalled, no change in behavior. Kind of at a loss here.
I had replaced flatpak.env, functionality was there, but this removed the applications from the launcher. I restarted GDM but don’t recall if I rebooted. Attempted to reinstall the applications and recover the launchers but that didn’t work so I uninstalled/reinstalled. In any case, the flatpaks are working again.
to see if that would update any of the missing paths but doesn’t seem to have made a difference. I’m spinning up a centos and fedora vm to test further so I can stop messing around with my primary machines.
This is consistent with what I see on Fedora 31 and Ubuntu 20.04.
The truth is I do see this error message when installing the authy snap:
$ sudo snap install --beta authy
Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not restarted your session
since you installed snapd, try doing that. Please see https://forum.snapcraft.io/t/9469
for more details.
authy (beta) 1.8.0 from Authy (authy-twilio) installed
$
Yet the authy snap works as expected on CentOS 8 despite the above error message.
My conclusions so far:
There’s an issue with snap that prints the above error message on CentOS 8. Yet this error message seems to be innocuous in my case - not to mean it does not need to be investigated of course. I have opened a different issue for this one: CentOS 8: /var/lib/snapd/snap/bin was not found in your $PATH.
I guess something’s messed up in the initialization process of your CentOS 8 machine because /var/lib/snapd/snap/bin is really missing from your $PATH. Not certain what to do about it, short of re-installing a clean machine. One more attempt though. On my Centos 8 and Fedora 31 virtual machines file /etc/environment is empty:
$ ls -l /usr/lib/environment.d/
total 4
lrwxrwxrwx. 1 root root 24 Mar 26 16:19 99-environment.conf -> ../../../etc/environment
-rw-r--r--. 1 root root 120 Feb 13 21:35 990-snapd.conf
$
$ realpath /usr/lib/environment.d/../../../etc/environment
/etc/environment
$
$ ls -l /etc/environment
-rw-r--r--. 1 root root 0 Oct 9 2019 /etc/environment
$
What does file /etc/environment look like on your CentOS 8 machine?
By the way, CentOS 8 is running Wayland by default here:
Also, running X11. although doesn’t seem that matters from your testing.
$ loginctl show-session $(awk ‘/tty/ {print $1}’ <(loginctl)) -p Type
Type=x11
Type=x11
$
I’m at a loss, I have 2 workstations with the same issue and the VM I installed earlier to test behaved the same way. I did install each from 8.0.1905 and then upgraded from there. Suppose I’ll give a shot to the 8.1 build in a vm and if that works I’ll rebuild my main workstation again.
Seems the only problem is the apps not getting dropped in the launcher. I can link them, annoying but definitely better than executing from command line and once it’s done then it’s done.
This is a know problem caused by using secure_path in sudo configuration in Fedora and RHEL. See https://bugzilla.redhat.com/show_bug.cgi?id=1691996 for more details. Unfortunately, there’s no known way for packages to drop-in configuration files to tweak that setting. Using sudo -E does the trick but IIRC it preserves too much of the environment and is thus not recommended.
With item 1 out of the way (use sudo --preserve-env=PATH instead of a mere sudo), there’s only item 2 left but I cannot reproduce it. The Authy icon is visible in Activities and clicking on it launches the application, then the icon appears in the panel and can be added to the Favorites.
The main difference you have noticed is that I installed the CentOS virtual machine from the CentOS 8.1.1911 DVD, while you installed 8.0.1905. However I would be surprised if that were the cause of the discrepancy. Any other peculiarities in your setup? My own setup is pretty simple: English (US) to be on the safe side, single Ethernet network interface, root account and single “sudoer” user, “dnf update” right after installation, then snapd installation from EPEL.
I really don’t know what else would be any different but I now have 4 different installs (2 physical and 2 virtual) with the same behavior. I pulled the latest iso last night, created a new VM on one of my centos servers, default options through the install, set a single user as admin during install. Post-install updated, installed EPEL, installed snapd and restarted my system. From there I followed snapstore’s page for signal-desktop and the app installed, but no icon in Activities.
The only thing that is coming to mind is at one point in testing last night I saw a message about snapd not being ready “device not seeded” or something, don’t recall the exact text, but I waited a couple minutes and attempted the app install again and it worked fine.
I logged into my test VM and installed the 2 groups you noted to make sure I had all the same packages, restarted the machine and tried to install authy. The install completed, with the warning at the end about /var/lib/snapd/snap/bin not found in $PATH as you already addressed. After install, nothing in activities to launch, but does launch via cmd. I’ve attached txt from journalctl during the install process and another showing the application launch, in case it’s useful. I really was expecting my VM to work fine at this point. This is frustrating, I have a workaround but I hate not being able to figure it out and fix it. Hopefully something in the attached files jumps out to you.
and the logging from cmd launch of authy, the part that looks odd to me here is the “Started flatpak…” line when launching a snap, but other than this is the timestamp I executed, I’m not sure it’s related or just coincidental.
Apr 24 17:09:30 cent dbus-daemon[2494]: [session uid=1000 pid=2494] Activating via systemd: service name=‘org.freedesktop.portal.Documents’ unit=‘xdg-document-portal.service’ requested by ‘:1.76’ (uid=1000 pid=4235 comm=“authy " label=“unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023”)
Apr 24 17:09:30 cent systemd[2464]: Starting flatpak document portal service…
Apr 24 17:09:30 cent dbus-daemon[2494]: [session uid=1000 pid=2494] Successfully activated service ‘org.freedesktop.portal.Documents’
Apr 24 17:09:30 cent systemd[2464]: Started flatpak document portal service.
Apr 24 17:09:38 cent dbus-daemon[1046]: [system] Activating via systemd: service name=‘org.bluez’ unit=‘dbus-org.bluez.service’ requested by ‘:1.474’ (uid=1000 pid=4235 comm=”/snap/authy/1/authy --no-sandbox " label=“unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023”)
Apr 24 17:10:03 cent dbus-daemon[1046]: [system] Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)