/etc/environment does not include /snap/bin in $PATH

Juju does not alter the PATH of the host except to add the tools directory for unit hook executions.

From IRC:

[11:59:52] <stokachu> so xenial server contains /snap/bin in $PATH but the cloud images do not

Yea it may be worthwhile talking to CPC team about getting that into the image builds

Yes, we discovered this today the hard way. It was really weird having to set path.

The snap layer has a workaround for reactive charms (it adjusts the path), leaving just traditional non-reactive actions affected.

Juju will need to adjust the PATH if CPC don't take on this bug, so I'd argue it should not be off the radar with an 'invalid' status.

I've looked at a GCE instance and a LXD container; both of these had /snap/bin in the path. This is configured by /etc/profile.d/apps-bin-path.sh, which is also in the downloadable images for xenial.

I'm not convinced that this is an issue in cloud-images, but I'm happy to be convinced so I'm going to mark this as Incomplete.

(I'll reopen the juju task so that this doesn't get lost.)

Just to clarify, I used MAAS provider at that time. It might be MAAS image specific, but I don't have handy MAAS env to confirm atm.

/etc/profile is for login shells, which explains how jujud and thus the hook environment fails to pick it up.

From what I can tell, /snap/bin needs to be added to the PATH in /etc/environment on all Ubuntu images.

This will also fix similar bugs with cron and other daemons, which also won't have /snap/bin in their PATH.

Looking at a xenial server and a zesty desktop/server, I don't think /etc/environment contains /snap/bin anywhere.

I'm running an ISO install now to confirm.

After installing from mini.iso:

$ cat /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

so I don't think this is an issue specific to the cloud images; once a fix is introduced to packages in the archive, we should pick it up automatically.

After speaking with the snappy team on IRC, asking for a change to /etc/environment is a big ask, and the idea of modifying it for existing installs also seems haphazard. It seems like sourcing /etc/profile or manually setting PATH is the next best thing, and is a workaround for the time being.

It's recommended to get insight from the Foundations team about other options, if any, that may allow solving this. Do note that /etc/profile is a bashism, as is the fact bash is treating login and non-login shells differently.

I'm marking the snapd task as invalid as we have no way to influence the global environment this way. There is a systemd feature that is not universally available yet that might allows us to do this but I also believe that the current approach of /etc/profile.d is as good as we can do it from the POV of our package.

Per https://bugs.launchpad.net/juju/+bug/1660273/comments/11 I've contacted Foundations

Foundations has not responded. How do we target this bug?

Reopening this for snapd, as the problem still exists. snapd packages can do the hazardous /etc/environment modification, or can coordinate with foundations for next Ubuntu release and backports.

You can add it in `/etc/profile.d`.

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.