On 2023-10-13 17:26:38, Julian Andres Klode wrote:
> On Fri, Oct 13, 2023 at 10:29:10AM -0400, Antoine Beaupré wrote:
>> On 2023-10-12 21:25:20, Kyle Fazzari wrote:
>> > On 10/11/23 22:45, Antoine Beaupré wrote:
>> >> On 2023-10-11 22:30:16, Kyle Fazzari wrote:
>> >>> On 10/11/23 19:24, Antoine Beaupré wrote:
>> >>
>> >> [...]
>> >>
>> >>> Yeah I won't lie, my immediate thought was "huh, I've never seen that
>> >>> happen." Then my follow-up was "actually, how would I even know?" But at
>> >>> the same time, I could make that argument for a lot of collectors! Is
>> >>> there an established pattern for gathering this kind of data?
>> >>
>> >> Filing a timestamp and duration of the last run is typical.
>> >
>> > Very good.
>> >
>> > By the way, I came across this Ubuntu bug today, which sounds eerily
>> > familiar, no?
>> >
>> > https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851
>>
>> Oh wow, so that would mean a bug in APT itself. And a regression too,
>> because we certainly never witnessed this in buster or bullseye...
>>
>> I wonder if we should clone this bug into apt...
>
> If you use apt-cacher-ng, stop using it. apt is *not* compatible
> with apt-cacher-ng. We already have bugs for that, and the only
> way things will change is if we gets https HTTP/2 on the mirrors
> and then can switch to libcurl.
We are not using apt-cacher-ng, and are now seeing this problem with
unattended-upgrades as well.
> Also please do not run apt update in the background or try to
> calculate dist upgrades, that is evil and you're breaking stuff.
> If you want to check for updates, make sure the periodic apt service
> is configured to run. You are entitled to one run per day. If you
> do not operate the mirror infrastructure please do not run your own
> updates out of band.
I agree this is a little odd and that the prometheus apt plugin should
probably not be the one handling the cache update.
What's the magic setting to make apt check those updates on its own? I
often get confused between unattended-upgrades and apt there...
> Then you may calculate the upgrade, but don't open the cache
> with locking so you don't go block other clients.
Could you expand on this? What's the proper pythonic way of doing this?
The script currently does:
cache = apt.cache.Cache()
with contextlib.suppress(apt.cache.LockFailedException,
apt.cache.FetchFailedException):
cache.update()
cache.open()
cache.upgrade(True)
What's the locking part here? Is this sufficient?
cache = apt.cache.Cache()
> Generally speaking it is likely that we will come up with a daemon
> on the road to Ubuntu 26.04 that you can ask to check for updates
> if it hasn't (again please don't if you don't own your infra) and
> then query for available upgrades; but it's nothing for the next 12 months.
Okay, that makes sense. So the Debian package here clearly has a bug
because it hits those mirrors every 15 minutes, that's definitely
something that needs to change.
> Also Kyle's emails don't arrive at all, well one did in the
> entire thread.
I'm not sure what to say about this... I don't have access to either
Kyle's, Ubuntu's or Debian.org infrastructure to diagnose this... Would
you prefer we move this discussion in the GitHub issue tracker or the
Launchpad issue?
Thanks for your feedback!
--
The reasonable man adapts himself to the world.
The unreasonable man persists in trying to adapt the world to himself.
Therefore, all progress depends on the unreasonable man.
- George Bernard Shaw
