Re: How do I permanently disable unattended downloads of software/security updates?
On Fri, Jun 04, 2021 at 02:15:24AM +0200, Stella Ashburne wrote:
> Output of systemctl list-timers | grep apt
>
> Thu 2021-06-03 20:29:30 GMT 9h left Thu 2021-06-03 09:18:00 GMT 1h 17min ago apt-daily.timer apt-daily.service
> Fri 2021-06-04 06:51:16 GMT 20h left Thu 2021-06-03 09:18:00 GMT 1h 17min ago apt-daily-upgrade.timer apt-daily-upgrade.service
Yes, you posted this already.
The point wasn't for you to copy and paste the output here and wait
for someone to hand-hold you through the next step. The point was
for you to read and understand the output yourself.
You've got these two systemd timers. Now you have their names, and you
know when they last triggered, and when they will trigger in the future.
Given their names (and the fact of their *existence*) you can investigate
further and learn what they do.
You could also correlate the time that the timer last triggered against
the time that the packages were downloaded, to confirm causality. If
you've waited too long, and the downloads actually occurred in a previous
cycle, then consider using "journalctl -u unitname" to get the full logs
from that unit.
Here are some more hints:
1) You can use "systemctl cat" followed by a unit name to get a dump of
the "unit file" (which may not be a single file) which defines that
unit.
2) Prior messages in this thread contain analysis of some of these
systemd units and the Debian tools that they call upon.
2a) The Debian tools that these units call have configuration files
which control what they do. Documentation is sketchy, but most
of these tools are scripts, so you can read the scripts. That's
part of the analysis that's already been done which you seem
to have skipped over.
3) Calling "systemctl disable" only works for *services*, and all it
does is remove them from the list of services that get launched at
boot time. It does nothing for units that are triggered by other
means than booting.
4) Calling "systemctl mask" will completely remove *all* possibility of
a unit being invoked, by booting, or by socket trigger, or being
called by some other unit, etc.
5) If journalctl isn't showing you logs from before your last reboot,
it's possible that you haven't enabled the persistent journal yet.
The persistent journal wasn't the default in Debian prior to (I think)
bullseye, which of course is not released yet.
To enable the persistent journal, see systemd-journald(8). There is
a simple two-line recipe in there.
6) Nobody knows what the fuck GNOME does. If GNOME's doing something
that you dislike, well, uh... that's unfortunate. But there's a
reason most of us don't run it. Several reasons, in fact.
Reply to: