Running several instances of snapcraft in parallel for a given snap name results in failures to acquire an apt lock file
Metadata
Current evaluation
Same-name builds from separate directories shared a provider instance and contended for APT locks; current code includes the project path inode in the instance name, resolving the collision.
Suggested action: close resolved
Reason: Commit 8a06cdbbd integrated path-derived provider naming, and current get_instance_name() includes project_path.stat().st_ino, giving same-named projects in separate directories distinct instances as proposed by cjp256. The optional --transient idea is absent, but it was ancillary to the reported lock failure.
Evaluated by: mr-cal-bot
Impact:
46
Quick Win:
25
Complexity:
38
Confidence:
94
Actionability:
86
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 |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
46
Quick Win:
25
Complexity:
38
Confidence:
94
Actionability:
86
|
close resolved | Same-name builds from separate directories shared a provider instance and contended for APT locks; current code includes the project path inode in the instance name, resolving the collision. | |
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
28
Complexity:
30
Confidence:
93
Actionability:
88
|
close resolved | Parallel same-name builds now get path-specific provider instances, preventing the shared VM and apt-lock collision; the optional --transient enhancement remains unimplemented. | |
| stealth/space-bunny-alpha |
Impact:
52
Quick Win:
16
Complexity:
60
Confidence:
93
Actionability:
78
|
needs triage | Parallel Chromium-channel builds with the same snap name contend for one multipass VM’s apt lock. Unique VM/container naming is proposed, but the report remains unlabelled and untriaged. | |
| qwen/qwen3.8-27b |
Impact:
35
Quick Win:
16
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. |
Update history
| Date | Change |
|---|---|
| created |
Related issues
No related issues found above the similarity threshold.