I have Authy installed on CentOS 8 and latest Fedora. Fedora works as expected, but CentOS does not. When I install in CentOS I get
$ sudo snap install authy --beta
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 How to fix snap binaries not found
for more details.
The install seems to have worked, I can execute Authy from the command line. Problem is, the application doesn’t show in the application folder and when it does execute it shows a “broken” icon on the panel. I am unable to add it to favorites or launch the application by any other means.
Yes, I’ve restarted the entire system. I also had the browser extension (and browser application) installed prior to the desktop application. I’ve since uninstalled both of those, performed removal of authy snap then reinstalled and restarted. I still do not have anything in my applications.
Launching authy from terminal starts the application with the below terminal output.
$ authy
Gtk-Message: 08:10:10.277: Failed to load module “pk-gtk-module”
Gtk-Message: 08:10:10.281: Failed to load module “pk-gtk-module”
TypeError: Cannot read property ‘then’ of undefined
at Function.AutoUpdater.init (/snap/authy/1/resources/app.asar/js/background.js:63011:22)
at Object.create (/snap/authy/1/resources/app.asar/js/background.js:56805:34)
at App.WindowHelper.create (/snap/authy/1/resources/app.asar/js/background.js:13678:32)
at App.emit (events.js:208:15)
[8591:0417/081010.613114:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
and Screenshot showing the “icon” (right-most icon) for running Authy Instance
I also attempted a clean installation today, the snap installs but does not put the application in the folder with the other applications. I was able to install the chrome app (not extension) and it shows in my applications and I can add that to favorites to launch more conveniently than command line. But I still get the notice at the top that the chrome app is not supported.
To make this more frustrating, after wiping and reinstalling my system now when I attempt to open the desktop app from command line I am unable to finish setting it up. It freezes looking up the country.
Add to this, also attempted to install signal-desktop snap - same result as with Authy. Install completes but does not leave apps in launcher and have to execute via command line. Signal was working prior to the OS reinstall.
For the install of each I saw -
$ sudo snap install signal-desktop
2020-04-20T21:51:48-07:00 INFO Waiting for restart…
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 How to fix snap binaries not found
for more details.
signal-desktop 1.33.1 from Snapcrafters installed
$ sudo snap install authy
error: snap “authy” is not available on stable but is available to install on the following
channels:
beta snap install --beta authy
edge snap install --edge authy
Please be mindful pre-release channels may include features not completely tested or
implemented. Get more information with 'snap info authy'.
$ sudo snap install authy --beta
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 How to fix snap binaries not found
for more details.
authy (beta) 1.8.0 from Authy (authy-twilio) installed
This has allowed both applications to execute as expected and show in the application launch as expected. I don’t know what I could have done wrong to require manual steps here. Initially, I did not have an issue with Signal, only Authy. After a clean install I had issue with both. I’ve not attempted further snap installs, but have no reason to expect different results at this point. What can I do to narrow this down and resolve it so I don’t continue to have issues?
I don’t think you have done anything wrong. The workaround that you did shows that XDG_DATA_DIRS as seen in GNOME shell process, does not contain the /var/lib/snapd/desktop path.
There is a systemd mechanism to add environment settings during user session startup, but for some reason it does not work in your system. What is the systemd version in your system? Try running rpm -qa systemd\*.
Then please collect the output of systemctl --user show-environment | grep '^XDG_DATA_DIRS'.
If you’re using GNOME shell, you can try opening the gnome shell debugger, try Alt+F2, type lg. In the debugger run GLib.getenv("XDG_DATA_DIRS").
I’ve tried both CentOS8 and RHEL8, with combinations of GNOME shell/classic sessions, on x11 and wayland. Also tried directly logging in followed by startx or dbus-run-session. In each of the tries, the icon showed up and XDG_DATA_DIRS was set correctly. I’m using snapd version 2.43.3-1.el8.
Please double check that /usr/lib/environment.d/990-snapd.conf is present. You can try and add some variable there, eg. FOO=1, then restart the session and verify that it’s really set. If it is, there’s perhaps something else overriding the XDG_DATA_DIRS environment variable.
As for adding something to 990-snapd.conf, I tried that and then Alt+F2 ‘r’ and the entry I added persisted. Is that adequate to restart the session or do I need to fully log out?
I think you need to log out and log back in. The entry you add should appear in your environment, visible in systemctl show-environment, lg and terminal.
If file /usr/share/gdm/env.d/flatpak.env is indeed the problem, then it would be a Flatpak bug, upstream of CentOS:
Now I cannot tell why /usr/share/gdm/env.d/flatpak.env (used by the Gnome Wayland graphical sessions) would be taken into account, or taken into account after and overwrite /usr/lib/environment.d/990-snapd.conf (used by systemd) in some cases and not others. Perhaps it is related to the version of Gnome and traditional vs. Wayland session startups: Initiatives/Wayland/SessionStart
@var38 What are the contents of the following directories?
/usr/lib/environment.d
/usr/share/gdm/env.d
@var38 Are you using an X11 or Wayland graphical session? See: How to know whether Wayland or X11 is being used
Ubuntu 20.04 opens X11 sessions by default and it works pretty well as both Flatpak and Snapcraft paths appear in XDG_DATA_DIRS:
$ loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type
Type=x11
$
$ ls -l /usr/lib/environment.d
total 4
lrwxrwxrwx 1 root root 16 Apr 14 00:05 99-environment.conf -> /etc/environment
-rw-r--r-- 1 root root 106 Apr 10 16:57 990-snapd.conf
$ ls -l /usr/share/gdm/env.d
total 4
-rw-r--r-- 1 root root 118 Mar 31 12:56 flatpak.env
$
$ echo $XDG_DATA_DIRS
/usr/share/ubuntu:/home/<username>/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
$
$ ls /usr/share/gdm/env.d/
flatpak.env
$ ls /usr/lib/environment.d/
990-snapd.conf 99-environment.conf
If flatpak.env is only used for Wayland is that something that can just be removed? As far as I know, I’m not running Wayland unless that changed when I reinstalled the other day. If I recall, the video card I’m using isn’t supported by Wayland so it’s not an option. Also, only have a few apps from flatpak - is that something that could be uninstalled or just the .env removed as a test?
I wouldn’t remove Flatpak for now. Perhaps temporarily move /usr/share/gdm/env.d/flatpak.env out of the way, for example:
sudo mv /usr/share/gdm/env.d/flatpak.env /
Then close and reopen your graphical session or better yet reboot. Does it help? What is the output of echo $XDG_DATA_DIRS? If it does help, we will still have to understand why this occurs on your CentOS machine but not your Fedora machine or my Ubuntu workstation. My gut feeling is that it is a Flatpak bug as it seems to be overwriting XDG_DATA_DIRS instead of adding to it:
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?
