Re: How do I permanently disable unattended downloads of software/security updates?
On Fri 04 Jun 2021 at 08:35:38 (-0400), Polyna-Maude Racicot-Summerside wrote:
> On 2021-06-04 7:59 a.m., Greg Wooledge wrote:
> > 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.
>
> No one asked you for opinion regarding a particular desktop environment
> or if it's a good choice to run it or not. Those type of comment are at
> least useless at most unproductive.
Actually, I find candid opinions posted here about software to be useful.
Many times I have written "I don't know anything about DEs as I don't
run one", but I don't expect my opinion to carry any weight here.
> Yes there's people who know what GNOME does and how it's done, there's
> even people who look into the source code... And people who investigated
> GNOME the same way you tell this guy to investigate some actions of the
> timers...
Nobody here is censoring them. But my impression is that we don't hear
from them very often.
> GNOME is part of the Debian distribution so this type of opinionated
> answer shall not arrive. This seem as sterile discussion as talking to
> some hard head politician... And it goes nowhere...
So I guess this means that around 58000 pieces of software should be
protected from having opinions passed on them. It hasn't worked out
so well for systemd.
Someone recently argued that respect for people here had to be earned
(I'm not sure how). I'd argue rather that it's their opinions that
have to earn respect, by being evaluated in the context of their other
contributions. We can then all make our own individual judgements.
Cheers,
David.
Reply to: