Closed tigarmo closed 8 months ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2539.
This message was autogenerated
Completed in: https://github.com/canonical/snapcraft/pull/4638
Bug Description
The fallback logic in
feature/craft-application
has an issue with handling of logs in managed (lxd/etc) instances. The flow is this - let's say that the command is "snapcraft pull".1) "Snapcraft-1" starts up on the host; 2) Realizes that the project has a non-core24 base, and falls back; 3) core22/core20 code picks up the execution, prepares the lxd instance; 4) launches Snapcraft in the instance with
SNAPCRAFT_MANAGED_MODE
set; 5) "Snapcraft-2" starts up inside the instance; 6) Like in 2, falls back to non-core24 code. However, before this, the Emitter is initialized - Snapcraft-2 thinks it's running on host because it's looking atCRAFT_MANAGED_MODE
and not atSNAPCRAFT_MANAGED_MODE
; 7) core22/core20 code in Snapcraft-2 picks up the execution, creates the lifecycle, runs "pull", finishes; 8) core22/core20 code in Snapcraft-1 tries to read the instance logs, but fails because Snapcraft-2 put it in/root/.local/state/snapcraft/logs
because it thought it was running on host.To Reproduce
Run a lifecycle command on any core22/core20 project using a Snapcraft snap from
feature/craft-application
, then look at the generated logs. The instance logs are not present.Environment
Jammy
snapcraft.yaml
Relevant log output
Additional context
No response