> To be clear, I’m not using ‘snap run’, just the ‘node’ that snap has put in the PATH, which is /snap/bin/node (a symlink to /usr/bin/snap). Lots of applications expect to be able to run ‘node’ from the PATH, including the ‘node’ snap’s own ‘npm’, ‘npx’, ‘yarn’, and ‘yarnpkg’ scripts.
Sure, node isn't calling snap run directly, but the act of calling /snap/bin/node (which is a symlink to /usr/bin/snap), correctly makes snap invoke the launcher via snap run. > If /snap/node/current/bin/node is expected to work better, then maybe it’s reasonable to ask why /snap/bin/node goes through /usr/bin/snap at all for a classic snap? Could snap just set it up as a direct symlink to /snap/node/current/bin/node and avoid this problem? We don't want snapd to do that since that would bypass the launcher entirely and even for classic snaps, we want the launcher to setup the environment and setup the process to be trackable by the system in various ways. Snaps calling their own binaries from $SNAP is the currently best supported method until we have the updates John mentioned. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849753 Title: AppArmor profile prohibits classic snap from inheriting file descriptors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
