staging job is failing with dpkg lock contention #7258
Assignees
Comments
legoktm
added a commit
that referenced
this issue
Oct 17, 2024
In edbc815, the process was refactored to use a two-pass system in which packages were first installed with `apt`, which would resolve dependencies, and then `dpkg`, which forcibly installed/overwrote existing packages. Recently we've been hitting trouble where the dpkg lock is still held and the second pass fails. We can do this all in one pass using apt though, by installing all the packages at once, so the dependency graph can be fullfilled, and by passing `--reinstall` to force the installation of the new debs. Fixes #7258.
2 tasks
github-project-automation
bot
moved this from In Progress
to Done
in SecureDrop dev cycle
legoktm
added a commit
that referenced
this issue
Oct 29, 2024
By enabling the services, it means it runs every time the machine boots, defeating the point of the timer. Similarly, starting the service means that it starts running while the playbook is still going, which might also explain the dpkg lock contention (#7258). Ansible will now just ensure the units are unmasked and the securedrop-config postinst will disable the services if enabled.
legoktm
added a commit
that referenced
this issue
Oct 29, 2024
By enabling the services, it means it runs every time the machine boots, defeating the point of the timer. Similarly, starting the service means that it starts running while the playbook is still going, which might also explain the dpkg lock contention (#7258). Ansible will now just ensure the units are unmasked and the securedrop-config postinst will disable the services if enabled. Fixes #7298
3 tasks
legoktm
added a commit
that referenced
this issue
Oct 29, 2024
By enabling the services, it means it runs every time the machine boots, defeating the point of the timer. Similarly, starting the service/timer means that it starts running while the playbook is still going, which might also explain the dpkg lock contention (#7258). Ansible will now just ensure the units are unmasked and the securedrop-config postinst will disable the services if enabled. Fixes #7298
legoktm
added a commit
that referenced
this issue
Nov 19, 2024
By enabling the services, it means it runs every time the machine boots, defeating the point of the timer. Similarly, starting the service/timer means that it starts running while the playbook is still going, which might also explain the dpkg lock contention (#7258). Ansible will now just ensure the units are unmasked and the securedrop-config postinst will disable the services if enabled. Fixes #7298
legoktm
added a commit
that referenced
this issue
Nov 23, 2024
By enabling the services, it means it runs every time the machine boots, defeating the point of the timer. Similarly, starting the service/timer means that it starts running while the playbook is still going, which might also explain the dpkg lock contention (#7258). Ansible will now just ensure the units are unmasked and the securedrop-config postinst will disable the services if enabled. Fixes #7298
legoktm
added a commit
that referenced
this issue
Nov 23, 2024
By enabling the services, it means it runs every time the machine boots, defeating the point of the timer. Similarly, starting the service/timer means that it starts running while the playbook is still going, which might also explain the dpkg lock contention (#7258). Ansible will now just ensure the units are unmasked and the securedrop-config postinst will disable the services if enabled. Fixes #7298
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
failed: [mon-staging] (item=securedrop-keyring_0.2.2+2.10.0+focal_all.deb) => {"ansible_loop_var": "item", "changed": true, "cmd": ["dpkg", "-i", "/root/securedrop-keyring_0.2.2+2.10.0+focal_all.deb"], "delta": "0:00:00.007442", "end": "2024-10-17 03:28:49.153608", "item": "securedrop-keyring_0.2.2+2.10.0+focal_all.deb", "msg": "non-zero return code", "rc": 2, "start": "2024-10-17 03:28:49.146166", "stderr": "dpkg: error: dpkg frontend lock is locked by another process", "stderr_lines": ["dpkg: error: dpkg frontend lock is locked by another process"], "stdout": "", "stdout_lines": []}failed: [mon-staging] (item=securedrop-ossec-server_3.6.0+2.10.0+focal_all.deb) => {"ansible_loop_var": "item", "changed": true, "cmd": ["dpkg", "-i", "/root/securedrop-ossec-server_3.6.0+2.10.0+focal_all.deb"], "delta": "0:00:00.008102", "end": "2024-10-17 15:21:57.993267", "item": "securedrop-ossec-server_3.6.0+2.10.0+focal_all.deb", "msg": "non-zero return code", "rc": 2, "start": "2024-10-17 15:21:57.985165", "stderr": "dpkg: error: dpkg frontend lock is locked by another process", "stderr_lines": ["dpkg: error: dpkg frontend lock is locked by another process"], "stdout": "", "stdout_lines": []} failed: [mon-staging] (item=ossec-server_3.6.0+focal_amd64.deb) => {"ansible_loop_var": "item", "changed": true, "cmd": ["dpkg", "-i", "/root/ossec-server_3.6.0+focal_amd64.deb"], "delta": "0:00:00.007470", "end": "2024-10-17 15:21:58.304197", "item": "ossec-server_3.6.0+focal_amd64.deb", "msg": "non-zero return code", "rc": 2, "start": "2024-10-17 15:21:58.296727", "stderr": "dpkg: error: dpkg frontend lock is locked by another process", "stderr_lines": ["dpkg: error: dpkg frontend lock is locked by another process"], "stdout": "", "stdout_lines": []}Not sure if this is related to the molecule upgrade or a race condition we've just exposed.
The text was updated successfully, but these errors were encountered: