Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apt module to first check for locks, then act accordingly #51959

Closed
Xophmeister opened this issue Feb 8, 2019 · 5 comments
Closed

apt module to first check for locks, then act accordingly #51959

Xophmeister opened this issue Feb 8, 2019 · 5 comments
Labels
affects_2.8 This issue/PR affects Ansible v2.8 feature This issue/PR relates to a feature request. module This issue/PR relates to a module. P3 Priority 3 - Approved, No Time Limitation packaging Packaging category support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@Xophmeister
Copy link

SUMMARY

An apt task will fail with the usual apt error message if apt is already running on a particular host. apt is often scheduled to run by, e.g., systemd or cron. The error that it spits out is a bit scary, but all you need to do is wait a few minutes for the previous apt invocation to finish. It would be nice if the apt module handled this for you automatically. That is:

  • Check for any apt locks and currently running apt processes
  • If there are any, either bailout, or try again after waiting -- perhaps this could be parametrised, somehow
  • If, after some maximum number of failures, report back to the user that apt is locked on the host and maybe some kind of manual intervention is required
ISSUE TYPE
  • Feature Idea
COMPONENT NAME

apt module

ADDITIONAL INFORMATION

Running apt processes on hosts are invisible to those running the orchestration (whether they're human or CI pipelines); e.g. #51663. If the output was more appropriate, it would avoid end user confusion.

@ansibot
Copy link
Contributor

ansibot commented Feb 8, 2019

Files identified in the description:

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot
Copy link
Contributor

ansibot commented Feb 8, 2019

@ansibot ansibot added affects_2.8 This issue/PR affects Ansible v2.8 feature This issue/PR relates to a feature request. module This issue/PR relates to a module. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Feb 8, 2019
@Xophmeister
Copy link
Author

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754103, which is a feature request to fix this upstream.

@s-hertel s-hertel removed the needs_triage Needs a first human triage before being processed. label Feb 12, 2019
@samdoran samdoran added the P3 Priority 3 - Approved, No Time Limitation label Feb 12, 2019
@ansibot ansibot added the packaging Packaging category label Feb 20, 2019
@tomwassenberg
Copy link
Contributor

This looks like a duplicate of #25414.

@bcoca
Copy link
Member

bcoca commented Apr 22, 2019

closing as dupe of #25414

@bcoca bcoca closed this as completed Apr 22, 2019
@ansible ansible locked and limited conversation to collaborators Jul 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.8 This issue/PR affects Ansible v2.8 feature This issue/PR relates to a feature request. module This issue/PR relates to a module. P3 Priority 3 - Approved, No Time Limitation packaging Packaging category support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

No branches or pull requests

6 participants