/snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

Bug #1771858 reported by Dan Watkins on 2018-05-17
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)
Status tracked in Cosmic
Xenial
Undecided
Unassigned
Bionic
Undecided
Unassigned
Cosmic
Critical
Michael Vogt
systemd (Ubuntu)
Status tracked in Cosmic
Xenial
Undecided
Unassigned
Bionic
Undecided
Unassigned
Cosmic
Undecided
Unassigned

Bug Description

[Impact]

 * 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.

description: updated
description: updated
Changed in systemd (Ubuntu Cosmic):
status: New → Won't Fix
Changed in systemd (Ubuntu Bionic):
status: New → Won't Fix
Changed in systemd (Ubuntu Xenial):
status: New → Confirmed
description: updated
summary: - /snap/bin not in default PATH for units
+ /snap/bin not in default PATH for units, snapd should ship system-
+ environment-generators to inject /snap/bin into $PATH
description: updated
Oliver Grawert (ogra) wrote :

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.

Oliver Grawert (ogra) wrote :

i meant to say above is that it would be nice to find a way that covers all use-cases with one code path (sorry, just noticed what i wrote wasnt clear in that regard)

Dimitri John Ledkov (xnox) wrote :

/etc/profile.d is for the login shells.

the bug is about the environment of systemd units as started by systemd. That environment is not created / does not parse /etc/profile.d

this new integration is to fix the environment as seen by binaries spawned by systemd (e.g. cloud-init). Specifically see my example $ systemd-run /usr/bin/env

Dimitri John Ledkov (xnox) wrote :

re:single code path

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.

Oliver Grawert (ogra) 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)

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.

--
Regards,

Dimitri.

Seth Arnold (seth-arnold) wrote :

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.

Thanks

Michael Vogt (mvo) wrote :

https://github.com/snapcore/snapd/pull/5226 <- contians a PR for this now.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu Bionic):
status: New → Confirmed
Changed in snapd (Ubuntu Xenial):
status: New → Confirmed
Changed in snapd (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
Robert C Jennings (rcj) wrote :

I'll mention this here because I believe it's related, if not please correct me and I'll file a separate bug. When cron jobs are run /snap/bin is not in the path.

Robie Basak (racb) wrote :

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.

Robie Basak (racb) wrote :

I filed bug 1777445 for the non-interactive ssh case.

Dimitri John Ledkov (xnox) wrote :

still not fixed in snapd.

Changed in snapd (Ubuntu Cosmic):
importance: Undecided → Critical
assignee: nobody → Michael Vogt (mvo)
Michael Vogt (mvo) wrote :
Dimitri John Ledkov (xnox) wrote :

Using this bug to fix systemd exported environment to the generators.

Changed in systemd (Ubuntu Cosmic):
status: Won't Fix → Fix Committed
Changed in systemd (Ubuntu Bionic):
status: Won't Fix → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 239-7ubuntu9

---------------
systemd (239-7ubuntu9) cosmic; urgency=medium

  * 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)

 -- Dimitri John Ledkov <email address hidden> Wed, 26 Sep 2018 11:01:58 +0100

Changed in systemd (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Changed in systemd (Ubuntu Bionic):
status: Confirmed → In Progress
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers