Running several instances of snapcraft in parallel for a given snap name results in failures to acquire an apt lock file
Metadata
Current evaluation
Parallel snapcraft builds for the same snap name share a multipass VM, causing apt lock file conflicts. Feature request to allow unique VM/container names. 6.4 years old, zero comments, no labels, no maintainer interaction.
Suggested action: close stale
Reason: The issue is 2350 days old with zero comments, no labels, and no maintainer interaction. The specific mechanism described (shared multipass VMs causing apt lock conflicts at /home/chrome-bot/.cache/snapcraft/stage-packages/apt/...) has been superseded by snapcraft's migration to LXD-based VMs, making the original error no longer reproducible in the same form. If the underlying need for unique VM names in parallel builds persists, it can be re-filed against the current LXD-based architecture.
Impact:
35
Quick Win:
15.75
Staleness:
95
Complexity:
55
Confidence:
55
Support Request:
20
Issue body
Use case: I'm working on upstreaming the snap packaging of chromium, and the chromium CI jobs try to build 3 snaps in parallel (for stable, beta and unstable). Those are initiated from three separate directories but different instances of snapcraft compete for the same apt lock file, because the three snaps have the same name, and thus use the same shared multipass VM.
This is the error:
Sorry, an error occurred in Snapcraft:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/apt/cache.py", line 67, in __enter__
return self._lock.__enter__()
SystemError: E:Could not get lock /home/chrome-bot/.cache/snapcraft/stage-packages/apt/0a910a73dbfd95c039f21b0fb2811cf7f339c9ad5da3b03eb5ba0c07fdc735c7cf8239eae76c933d6abf4a5b5847feff/var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
Should snapcraft allow specifying a unique VM/container name, to avoid clashes?
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
35
Quick Win:
15.75
Staleness:
95
Complexity:
55
Confidence:
55
Support Request:
20
|
close stale | Parallel snapcraft builds for the same snap name share a multipass VM, causing apt lock file conflicts. Feature request to allow unique VM/container names. 6.4 years old, zero comments, no labels, no maintainer interaction. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
65
Confidence:
75
Support Request:
15
|
close stale | Parallel snapcraft builds for the same snap name conflict over apt lock files in a shared multipass VM. The issue is six years old with no maintainer response or labels. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
60
Confidence:
85
Support Request:
20
|
close stale | Parallel snapcraft builds for the same snap name fail due to shared apt lock files in a multipass VM. Issue is over six years old with no maintainer response. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
65
Confidence:
85
Support Request:
20
|
close stale | Parallel snapcraft builds for the same snap name fail due to shared apt locks in a single multipass VM. Issue is six years old with no maintainer response or labels. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
65
Confidence:
75
Support Request:
15
|
needs triage | Parallel snapcraft instances for the same snap name compete for a shared apt lock file via a multipass VM. The issue is unlabelled, has zero comments, and has been inactive for over six years. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1889741 Snapcraft concurrent build | snapcraft (launchpad) | open | Race condition when running multiple snapcraft instances concurrently: both check for $HOME/.cache/snapcraft/download and stage-packages, both see missing, one creates, other fails. Reported ~6 years ago, 0 comments, no maintainer response, no labels. | |
| #2013112 Installing snapcraft under a different name causes version mixup | snapcraft (launchpad) | closed | The snapcraft parallel install version mixup was closed without resolution. With zero comments and over three years of inactivity, the bug was abandoned and remains unfixed. |