Bug Description

* This means that software installed via snap isn't transparently available for units to use. As snaps are first-class citizens in Ubuntu, we should update the PATH.

* When a generator started to be provided by systemd, it was recognized that $PATH is not correctly set, nonetheless, due to an environment bug that systemd generators run in.

[Testcase]

$ systemd-run /usr/bin/env
$ journalctl -e | grep PATH

Output should contain /snap/bin

Output should contain a complete and a valid PATH, i.e.
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" or similar.

[Regression Potential]

* snapd generator was already fixed separately to cause no harm, when running under a broken systemd. With the corrected environment, generators will now run with a correct PATH out of the box. A slight change of PATH will be observed by all generators, when running in containers/initramfs-less boots. However most generators will not be affected as they typically do not execute external binaries.

snapd ships a snippet in /etc/profile.d that sets the PATH to /snap/bin and should theoretically work for all login shells (except for zsh which doesn't respect the profile.d standard) ... bug 1640514 and bug 1659719 are related.

we do have a lot of duplication. I think profile.d is actually good enough for all the logged in users. However, for now, the /usr/lib/systemd/system-environment-generators is a special place to integrate and ensure that environment that systemd creates for units has everything setup correctly.

well, my subtle hint would point to simply add it to /etc/environment here, which would globally cover for everything, would allow us to drop the profile.d snippet in ubuntu images/installs and to my knowledge would even be used by systemd (or am i wrong here ?) ...

On 18 May 2018 at 19:01, Oliver Grawert <email address hidden> wrote:
> well, my subtle hint would point to simply add it to /etc/environment
> here, which would globally cover for everything, would allow us to drop
> the profile.d snippet in ubuntu images/installs and to my knowledge
> would even be used by systemd (or am i wrong here ?) ...
>
> (and i think it would even work for zsh)
>

Sorry, I do not have time for subtle hints.

As you are well aware, snapd cannot modify /etc/environment; (not
owned by it, it is freeform text, can contain anything, may or may not
have PATH setting, not-upgradable, so on and so forth)
said file is not used by systemd;
it would not cover things globally;
and specifically it would not cover things across other distributions.

There are reasons why integration snippet was shipped by snapd in
profile.d, and all of those reasons still stand.

And more-over the ethos for snapd packaging is to integrate into as
many systems as possible, in a native way.
Shipping appropriate system-environment-generators will achieve that
not only on Ubuntu classic installs but on any systemd-based Linux
distros too, which my understanding is the scope for the snapd
project.

On Fri, May 18, 2018 at 06:01:19PM -0000, Oliver Grawert wrote:
> well, my subtle hint would point to simply add it to /etc/environment
> here, which would globally cover for everything, would allow us to drop

Note that /etc/environment is only used by PAM-aware services that have
been configured to use pam_env in the corresponding /etc/pam.d/ files.

systemd will not use PAM when launching services.

This might still match your idea of "everything" but I wanted to make sure.

A related issue is that "ssh <host-with-snaps> <snap-command>" currently fails because /snap/bin isn't in PATH. In that case, sshd sets PATH via pam_env. I'm not sure if a systemd environment generator will help with this use case or not.

* core: export environment when running generators.
Ensure that manager's environment (including e.g. PATH) is exported when
running generators. Otherwise, one is at a mercy of running without PATH which
can lead to buggy generator behaviour. (LP: #1771858)

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.