Hi, 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. 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... 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... -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature