saltstack / saltstack/salt

pkg.installed does not handle dkpg frontend lock error

Open
#60,627 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
15.7k
Forks
5.6k
Avg merge
2d 44m
Merged PRs (30d)
80

Description

Description
A clear and concise description of what the bug is.

Setup
Debian Buster Salt 3003

Steps to Reproduce the behavior
Have unattended upgrades, or other process, hold a lock on dpkg and run a salt pkg.install command.

Logs will result in

021-07-26 15:10:03,588 [salt.loaded.int.module.cmdmod:853 ][ERROR   ][1026] Command 'apt-get' failed with return code: 100
2021-07-26 15:10:03,588 [salt.loaded.int.module.cmdmod:855 ][ERROR   ][1026] stdout: Reading package lists...
2021-07-26 15:10:03,588 [salt.loaded.int.module.cmdmod:857 ][ERROR   ][1026] stderr: E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/lib/apt/lists/
2021-07-26 15:10:03,588 [salt.loaded.int.module.cmdmod:859 ][ERROR   ][1026] retcode: 100
2021-07-26 15:10:03,601 [salt.loaded.int.module.aptpkg:181 ][WARNING ][1026] Waiting for dpkg lock release: retrying... 1/100
2021-07-26 15:10:06,795 [salt.loaded.int.module.cmdmod:853 ][ERROR   ][1026] Command 'systemd-run' failed with return code: 2
2021-07-26 15:10:06,795 [salt.loaded.int.module.cmdmod:857 ][ERROR   ][1026] stderr: Running scope as unit: run-r446eb9308c4c4d8790489e52139a7270.scope
dpkg: error: dpkg frontend lock is locked by another process
2021-07-26 15:10:06,795 [salt.loaded.int.module.cmdmod:859 ][ERROR   ][1026] retcode: 2
2021-07-26 15:10:06,823 [salt.state       :321 ][ERROR   ][1026] Made the following changes:
'amazon-ssm-agent' changed from '3.0.1390.0-1' to 'absent'

You can see the "Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)" error was handled and retried, but the "dpkg: error: dpkg frontend lock is locked by another process" error is not retried.

Expected behavior
Expect pkg.installed to handle dpkg locks correctly and retry.

Versions Report

Salt Version:
          Salt: 3003

Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.7.3
     docker-py: Not Installed
         gitdb: 4.0.7
     gitpython: 3.1.18
        Jinja2: 2.10
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: 2.6.1
  pycryptodome: 3.6.1
        pygit2: Not Installed
        Python: 3.7.3 (default, Jan 22 2021, 20:04:44)
  python-gnupg: Not Installed
        PyYAML: 3.13
         PyZMQ: 17.1.2
         smmap: 4.0.0
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.1

System Versions:
          dist: debian 10 buster
        locale: UTF-8
       machine: x86_64
       release: 4.19.0-16-cloud-amd64
        system: Linux
       version: Debian GNU/Linux 10 buster

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start from the pkg.installed implementation and its existing apt lock retry handling. Reproduce the Debian Buster case with a held dpkg frontend lock, then verify that the reported dpkg lock error is retried consistently with the apt lock error and that the package state is not incorrectly reported.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devops
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.