[4.0.7] hook environment does not contain snap-specific PATH and LD_LIBRARY_PATH (as it used to)

[Dmitrii Shcherbakov]

snapcraft used to generate hook wrappers under meta/hooks/<hook-name> which contained

#!/bin/sh
export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/lib/x86_64-linux-gnu"
export LD_LIBRARY_PATH="$SNAP/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/lib/x86_64-linux-gnu/ceph:$SNAP/zfs-0.6/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH"
exec "$SNAP/snap/hooks/install" "$@"

https://github.com/snapcore/snapcraft/blob/4.0.7/snapcraft/internal/meta/_snap_packaging.py#L546-L562
https://github.com/snapcore/snapcraft/blob/4.0.7/snapcraft/internal/meta/_snap_packaging.py#L462

However, this is no longer the case which leads to subtle errors.

Example (only visible if SNAPD_DEBUG=1 is set for snapd):

* the remove hook gets called during the snap removal;
* a binary gets executed in the hook which needs a shared library from a snap-specific LD_LIBRARY_PATH;
* the hook silently fails without performing the necessary cleanup.

Jun 26 13:17:01 node-hagecius snapd[28196]: taskrunner.go:437: DEBUG: Running task 7199 on Do: Run remove hook of "microstack" snap if present
Jun 26 13:17:01 node-hagecius snapd[28196]: task.go:337: DEBUG: 2020-06-26T13:17:01Z ERROR ignoring failure in hook "remove":
Jun 26 13:17:01 node-hagecius snapd[28196]: -----
...
Jun 26 13:17:01 node-hagecius snapd[28196]: DEBUG: execv(/usr/lib/snapd/snap-exec, /usr/lib/snapd/snap-exec...)
Jun 26 13:17:01 node-hagecius snapd[28196]: DEBUG: argv[1] = --hook=remove
Jun 26 13:17:01 node-hagecius snapd[28196]: DEBUG: argv[2] = microstack
Jun 26 13:17:01 node-hagecius snapd[28196]: DEBUG: umask restored to 022
Jun 26 13:17:01 node-hagecius snapd[28196]: DEBUG: working directory re-interpreted to /
Jun 26 13:17:01 node-hagecius snapd[28196]: + /snap/microstack/current/usr/local/bin/ovs-vsctl --if-exists del-br br-ex
Jun 26 13:17:01 node-hagecius snapd[28196]: /snap/microstack/current/usr/local/bin/ovs-vsctl: error while loading shared libraries: libunbound.so.8: cannot open shared object file: No such file or directory
Jun 26 13:17:01 node-hagecius snapd[28196]: -----
Jun 26 13:17:01 node-hagecius snapd[28196]: taskrunner.go:437: DEBUG: Running task 7200 on Do: Disconnect interfaces of snap "microstack"

I understand that there was a design goal to remove wrappers

https://forum.snapcraft.io/t/proposal-support-command-chain-in-apps-and-hooks/6112

but this seems like a major breaking change.

Could snap.yaml be modified for a generated snap to include PATH and LD_LIBRARY_PATH (seeing how https://github.com/snapcore/snapd/pull/5498 got merged a while ago)?

[Sergio Schvezov (sergiusens)]

Hooks can accept a command-chain:
- if the hook was "installed" through a part we probably want to add the snapcraft-runner script into command-chain as we do for apps (I believe we do this already in the form of a wrapper and we need to upgrade to command chain)
- if the hook was in the project root ($PROJECT_ROOT/snap/hooks/remove) then it is assumed you setup everything correctly and we just copy it over.

This behavior has not changed for hooks.

We don't add environment as it is not a list and there would be no easy way to override for a developers point of view.

Silently failing hooks is a snapd issue.

[Paweł Stołowski (stolowski)]

Snapd ignores hook errors only in a few very specific cases - one of them is remove - and that's by design (and it is that way the beginning of hooks support) since we don't want to prevent snap removal due to a bug in remove hook (which would be hard to recover from for the user); in other cases such as install hook we would fail the installation since such problem can and should be corrected by the publisher of the snap.

Such failures are not completely silent though, they are logged on the associated tasks (with "ignoring failure in hook: ..." message) and can be seen at the bottom of `snap change X` output.

[Launchpad Janitor (janitor)]

[Expired for Snapcraft because there has been no activity for 60 days.]