On a fresh install of Kubuntu and fish shell my snaps are not in PATH

[Dean Maniatis]

I get the following error when trying to launch any downloaded snaps (e.g. Slack, Hexchat, etc.). I'm using Fish shell as default

```
The command could not be located because '/snap/bin' is not included in the PATH environment variable.
hexchat: command not found
```

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: snapd 2.38+18.04
ProcVersionSignature: Ubuntu 4.18.0-21.22~18.04.1-generic 4.18.20
Uname: Linux 4.18.0-21-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: KDE
Date: Thu Jun 13 09:28:11 2019
InstallationDate: Installed on 2019-06-10 (2 days ago)
InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)

[Sebastien Bacher (seb128)]

Could be the same as https://github.com/snapcore/snapd/pull/6813

[Michael Vogt (mvo)]

This sounds like the fish shell maybe does do something fishy (sry for the pun) with the /etc/environment. In snapd 2.41 we use a systemd generator to create the right PATH on bootup, so this version (which wil be availalbe as a deb in *-updates shortly) should fix this issue.

[Zygmunt Krynicki (zyga)]

Is this still a problem. The 2.41 release is out in the wild for a while now.

Dear reporter, can you still reproduce the issue with the Debian package of snapd 2.41?

[Piotr Martycz (pmartycz)]

I can confirm it did work for some time but has regressed lately in 20.04.

The snap paths are missing from environment when login shell is /usr/bin/fish

pmart@t420 ~> systemctl show-environment --user | grep -e '^PATH' -e '^XDG_DATA'
PATH=/home/pmart/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
XDG_DATA_DIRS=/usr/share/plasma:/usr/local/share/:/usr/share/

After changing it to /usr/bin/bash and relogging

pmart@t420:~$ systemctl show-environment --user | grep -e '^PATH' -e '^XDG_DATA'
PATH=/home/pmart/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
XDG_DATA_DIRS=/usr/share/plasma:/usr/local/share:/usr/share:/var/lib/snapd/desktop

Applies to both sddm and login(1) sessions.

I tried to investigate further. It seems PATH for user sessions is now set by

1. systemd-environment-d-generator based on /etc/environment and its own config
2. pam_env.so module based on /etc/environment and optionally ~/.pam_environment (overrides above?)
3. some other source where ~/.local/bin path is coming from

Btw my /etc/environment contents are

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

and I'm not sure whether I have configured it explicitly or this is the default (file is not owned by any package)

[M-A Harvey (ma-harvey)]

Wow! This puzzled me for a while.

On a fresh Ubuntu Server 18.04 install. snap up to date. It turns out that in my case, the issue was caused by a change in Debian's default behavior of the su command.
https://unix.stackexchange.com/questions/460478/debian-su-and-su-path-differences

Since package installs require elevated privileges, it is useful to just type "sudo su" and install all the required packages. See for yourself:

user@ubuntu-hyperv-vm:~$ sudo su
root@ubuntu-hyperv-vm:/home/user# echo $PATH && exit
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

exit
user@ubuntu-hyperv-vm:~$ sudo su -
root@ubuntu-hyperv-vm:~# echo $PATH && exit
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
logout

I traced down the issue to the /etc/profile. This file is only loaded when typing "sudo su -", which in turn calls the /etc/profile.d/apps-bin-path.sh script where the snapd fix to keep the path is placed.

I have no clue where the true fix to enable it would need to be inserted. Perhaps modifying the /etc/pam.d/su config file or something.