On Mon 05 Oct 2026 at 17:38:52 (+0200), [email protected] wrote:
> On Mon, Oct 05, 2026 at 08:59:24AM -0500, David Wright wrote:
> > On Mon 05 Oct 2026 at 06:29:12 (-0600), Charles Curley wrote:
> > > On Sun, 4 Oct 2026 20:29:59 -0400
> > > Dan Purgert <[email protected]> wrote:
> > > > On Oct 04, 2026, Charles Curley wrote:
> > > > > How do I tell which apt cache did I use, if any, when running "apt
> > > > > update" or "apt upgrade"? I use auto-apt-proxy to detect apt
> > > > > proxies.
> > > >
> > > > If I'm reading the question correctly, your system will use the
> > > > repository configured in /etc/apt/sources.list (or, if you're using
> > > > the newer format, I think it's /etc/apt/xxx.sources -- although
> > > > ILately haven't done a new-install yet, so I don't know the exact
> > > > filename)
> > > >
> > > > Unless your network integrates a proxy (e.g. I dunno, a university
> > > > campus), then chances are there is no proxy.
> > >
> > > Sorry for the lack of context. I've been running a small office/home
> > > (SOHO) network for several decades, starting in dial-up modem days, and
> > > that has included an apt proxy server since then. Lately I have been
> > > running apt-cacher-ng, and I am experimenting with apt-cacher-ultra. I
> > > use auto-apt-proxy to detect the proxy. So the question is, did a given
> > > run of apt use a proxy, and if so which one?
> >
> > I only know about apt-cacher-ng, which logs its use in
> > /var/log/apt-cacher-ng/apt-cacher.log, helping you to
> > distinguish between two potential servers.
>
> I had a look at an apt client, and at least in /var/log/apt I can't find
> any trace of the cache. It seems APT doesn't know about it (after passing
> it to the HTTP library).
That's right, and that's the OP's problem. But what the APT client
does log is (using as an example the same instance in my post above):
Start-Date: 2026-10-01 23:25:46
Commandline: apt-get upgrade
Upgrade: chromium:amd64 (154.0.8037.57-1~deb13u1, 154.0.8037.92-1~deb13u1), …
End-Date: 2026-10-01 23:25:50
Translating the Start-Date on the client:
$ date +%s --date 2026-10-01T23:25:46
1790915146
$ ip a | grep 192.168
inet 192.168.1.17/24 brd 192.168.1.255 scope global noprefixroute eno2
$
To explain why apt-cache-ng downloaded chromium eight seconds before
the client apparently asked it to, you need to see the client's
command line:
# apt-get -o Acquire::http::Proxy="http://192.168.1.16:3142/"; update \
&& apt-get -d -o Acquire::http::Proxy="http://192.168.1.16:3142/"; \
dist-upgrade; apt-get upgrade; read -p 'Ctrl-C to avoid clean' _; \
apt-get clean ### TRIXIE
I have to respond at each stage, eg (though the text, as opposed to
the timings, is not from this run as it's not recorded):
time_t=1790915127 update seen on server
Fetched 311 kB in 0s (934 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
Do you want to continue? [Y/n]
time_t=1790915138–1790915141 download performed on server
[ At this point, nothing shows in the APT client's log ]
Need to get 0 B/105 MB of archives.
After this operation, 17.4 kB of additional disk space will be used.
Do you want to continue? [Y/n]
time_t=1790915146 Start-Date: 2026-10-01 23:25:46 seen in client log
So I'm using timings to tie the client to the server/proxy pair.
I would presume that a proxy not selected by auto-apt-proxy would
show no evidence of its being hit. Repeating my disclaimer, I only
know what apt-cacher-ng logs, and not what other cachers record.
Unlike some others here, apt-cacher-ng hasn't given me cause to
look at apt-cacher-ultra. Any problems I've had in the past can
usually be put down to running apt-cacher-ng on a system that's
serving clients one or even two Debian versions ahead, something
I'm trying to avoid nowadays.
Cheers,
David.
