[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#864681: marked as done (Apt ux improvment: retry on lock aquisition)



Your message dated Thu, 9 Apr 2020 08:48:23 +0200
with message-id <[🔎] 20200409084522.GA755617@debian.org>
and subject line Re: Bug#864681: Apt ux improvment: retry on lock aquisition
has caused the Debian Bug report #864681,
regarding Apt ux improvment: retry on lock aquisition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
864681: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864681
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apt
Version: 1.4.6


In working on: https://bugs.launchpad.net/cloud-init/+bug/1693361, as
well as many other pieces of software throughout my time working with
Ubuntu, the lack of a retry on lock acquisition is certainly an area
where apt and libapt could improve.

As it stands, all client applications that interact with Apt are
burdened with similar boilerplate concepts of blind retries with backoff
algorithms.

A single command line with more advanced config settings would probably
satisfy the bulk of use cases.

  apt --retry-lock-timeout 30

With NEVER being the default (forever), and duration to retry in minutes as
the accepted parameter, 0 meaning, don't retry, or timeout immediately.


-- 
David Britton <david.britton@canonical.com>

--- End Message ---
--- Begin Message ---
Version: 1.9.11

On Tue, Jun 13, 2017 at 10:59:46PM +0200, Julian Andres Klode wrote:
> Control: tag -1 confirmed
> 
> On Mon, Jun 12, 2017 at 02:01:01PM -0600, David Britton wrote:
> > Package: apt
> > Version: 1.4.6
> > 
> > 
> > In working on: https://bugs.launchpad.net/cloud-init/+bug/1693361, as
> > well as many other pieces of software throughout my time working with
> > Ubuntu, the lack of a retry on lock acquisition is certainly an area
> > where apt and libapt could improve.
> > 
> > As it stands, all client applications that interact with Apt are
> > burdened with similar boilerplate concepts of blind retries with backoff
> > algorithms.
> > 
> > A single command line with more advanced config settings would probably
> > satisfy the bulk of use cases.
> > 
> >   apt --retry-lock-timeout 30
> > 
> > With NEVER being the default (forever), and duration to retry in minutes as
> > the accepted parameter, 0 meaning, don't retry, or timeout immediately.
> 
> I have indeed been thinking about waiting for locks.

Since 1.9.11, apt(8) now waits for dpkg locks by default, apt-get(8) needs to be
passed -o dpkg::lock::timeout=$seconds, where $seconds is either the
seconds to wait or -1 to wait indefinitely.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

--- End Message ---

Reply to: