[CONFIGURATION] software update frequency preferences are ignored

[chconnor]

Howdy -- a year or two ago I posted this thread, which led to this "fixed" bug, but the problem persists in my fresh 20.04 install, so I'm not sure if it was actually addressed?

If I go to Muon -> Settings -> Configure Software Sources -> <enter pw> -> Updates -> Check for updates: and set it to "weekly", this setting is ignored. Updates are checked by discover all the time, often once a day (or more?).

Previously there was apparently no way to convince Discover not to update constantly -- has this issue been addressed? Is there any way to tame it? A different setting somewhere? A config file or cron job or anything?

Thanks for any tips!

[jlittle]

ignored indeed. I did a little bit of a source dive, and found that:

1. Updates -> Check for updates: and set it to "weekly" sets the APT configuration variable APT::Periodic::Update-Package-Lists to "7" in /etc/apt/apt.conf.d/20auto-upgrades.
2. The only place in the discover source code that looks at that variable, reads it, then ignores it with the comment
   

             //if the setting is not empty, refresh will be carried out by unattended-upgrade
             //https://wiki.debian.org/UnattendedUpgrades

   I don't understand what it does next, or how that comment applies. I suspect that the need for lots of security fixes in the last few years, letting things update according to a user's wishes was discarded.

[kubicle]

ignored indeed. I did a little bit of a source dive, and found that:

1. Updates -> Check for updates: and set it to "weekly" sets the APT configuration variable APT::Periodic::Update-Package-Lists to "7" in /etc/apt/apt.conf.d/20auto-upgrades.
2. The only place in the discover source code that looks at that variable, reads it, then ignores it with the comment
   

           //if the setting is not empty, refresh will be carried out by unattended-upgrade
           //https://wiki.debian.org/UnattendedUpgrades

   I don't understand what it does next, or how that comment applies. I suspect that the need for lots of security fixes in the last few years, letting things update according to a user's wishes was discarded.

The comment seems to refer to the apt configuration check before it (note the indentation), unattendedupgrades also uses the "APT::Periodic::Update-Package-Lists" so the comment basically says that if the configuration is set updatenotifier should not handle automatic list update frequency as it's handled by other software (and the comment assumes it's unattendedupgrades, even though the setting can obviously be set by muon...or even manually).

I didn't go through the code with a comb, and can't check whether it currently fails or not as I do not have any of the software involved installed (muon, updatenotifier, discover or unattended-upgrades). Logic seems sound at a glance, but there might be a bug that isn't immediately apparent (or maybe someone has touched the code since the patch).

https://phabricator.kde.org/D17375

[Don B. Cilly]

I'm not sure about the OP's actual needs, but what I do here is
1) Disable the updates notification in the panel. So I don't see the icon.
2) sudo apt remove --purge unattended-upgrades

Which fits my needs perfectly.
Then, when I want to see what's up, I run
apt list --upgradable
and so on. Actually, I use my "micro-muon" ;·) for that stuff, which makes it really easy.


[NOTE] I positively hate unattended-upgrades. They tend to update kernels, FPS, without saying anything. That clogs resources, messes up rEFInd, etc.
[NOTE2] The "micro-muon" does most of what muon does, but doesn't clog resources with the xapian updates and stuff :·)

[jlittle]

Having looked at it some more I think the supposed fix is quite broken.

After googling for a while, seeing pleas from folks who absolutely need discover not to run all the time, drastic measures are resorted to: either removing plasma-discover altogether (carefully), or disabling /usr/lib/packagekit/packagekitd by taking off the execute flags. Disabling the systemd services does not stop the update checks at boot time.

[Don B. Cilly]

If by "update checks at boot time" you mean the dreaded update-apt-xapi process, which used to annoy me to distraction on K18, Neon and K20 don't do it. Not at boot.
If they do something else, it takes no resource. I really keep an eye on my CPUsage.

[kubicle]

If by "update checks at boot time" you mean the dreaded update-apt-xapi process, which used to annoy me to distraction on K18, Neon and K20 don't do it. Not at boot.
If they do something else, it takes no resource. I really keep an eye on my CPUsage.

That's a different problem.

What the update-notfier is supposed to do (the code logic) is that is runs daily package list updates ("apt update") if the the APT::Periodic::Update-Package-Lists apt.conf variable is not set (or is set to zero), it shouldn't do that if the variable is set to non-zero (days). The variable can be set in muon,unattended-upgrades debconf or manually (and possibly with other apt tools). The OPs problem seems to be that the list updates happen even if the conf is set to "7" days.

@jlittle, care to elaborate what you think is wrong with the code, as I can't debug or troubleshoot the problem without installing all of it.

[Don B. Cilly]

Indeed. But :·)
The "impact" of apt update here is this:



That is, pretty much unnoticeable. Update-apt-xapi looked something like this:



And went on "for ages".
That of "unattended-upgrades" - especially when updating kernels - was, all CPUs at 100% "forever". :·)

So, not having the xapian thing at boot is (to me) a huge advantage.
Even though I have seen it recently (not at boot, at "muon" :·) and nowadays it seems to run in much "nicer" mode.

That said, and back to the point, I remember trying to set updates to a week or so, failing, and doing the "other thing" (uninstall unattendeds and disable notifications).
That makes it so that, in practice, I don't see anything to do with updates ever unless I want to. Which, however lazy I get, is a lot oftener than a week.
So I thought maybe "in practice" it could be a viable solution for the OP.

[kubicle]

Indeed. But :·)
That said, and back to the point, I remember trying to set updates to a week or so, failing, and doing the "other thing" (uninstall unattendeds and disable notifications).
That makes it so that, in practice, I don't see anything to do with updates ever unless I want to. Which, however lazy I get, is a lot oftener than a week.
So I thought maybe "in practice" it could be a viable solution for the OP.

Could be, but the OP might actually want to see the notifications (but doesn't need to check them daily). And I'm not sure (although I can't be sure without checking the code) whether "disabling notifications" actually stops it from updating the package lists daily. After all, "apt list --upgradable" doesn't do much if you don't run update regularly (it only shows available upgrades since last package list update).

And in any case, if the code is bugged it should be fixed.

I positively hate unattended-upgrades. They tend to update kernels, FPS, without saying anything. That clogs resources, messes up rEFInd, etc.

You can configure unattended-upgrades to just update the package list periodically, without actually installing any updates if you wish. (of course you can do that a multitude of other ways, too)

[chconnor]

Thanks for the detailed look, everyone. I can disable the update notifications in the panel if I need to, but I'd actually like to be notified as a reminder to do it, so it'd not be ideal.

I do set upgrades to "only notify" in muon, and that is respected. But as some have noted, it seems like a clear bug that the "every 7 days" is ignored.

jlittle -- if you have more insight to code specifics, I will await that, and I'll volunteer to file another bug against Discover (assuming that's the appropriate place.) (That will basically be duplicating the one I filed before, so maybe I'll just re-open that.)

[claydoh]

Have we considered that apt itself sets a service that at least checks for updates regularly, and also performs whatever unattended-upgrades is set to do?

/lib/systemd/system/apt-daily.timer and/or apt.daily-service

[FONT=monospace][COLOR=#000000] apt-daily-upgrade.service        loaded    inactive dead    Daily apt upgrade and clean activities            [/COLOR]
  apt-daily.service                loaded    inactive dead    Daily apt download activities         

[/FONT]

[FONT=monospace][COLOR=#000000]$ systemctl list-timers | grep apt[/COLOR]
Thu 2020-05-07 01:49:51 EDT  6h left       Wed 2020-05-06 06:22:49 EDT  12h ago      [COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily.timer              [/COLOR][COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily.service[/COLOR]
Thu 2020-05-07 06:14:17 EDT  11h left      Wed 2020-05-06 06:05:49 EDT  12h ago      [COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily-upgrade.timer      [/COLOR][COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily-upgrade.s[/COLOR]ervice

[/FONT]

So I wonder if this core timer apt uses runs, and at some point packagekit/discover notices this later?


https://unix.stackexchange.com/quest...cloud-vm-image
https://unix.stackexchange.com/quest...d-it-come-from
https://wiki.debian.org/UnattendedUp...8on_systemd.29

[kubicle]

Have we considered that apt itself sets a service that at least checks for updates regularly, and also performs whatever unattended-upgrades is set to do?

/lib/systemd/system/apt-daily.timer and/or apt.daily-service

[FONT=monospace][COLOR=#000000] apt-daily-upgrade.service        loaded    inactive dead    Daily apt upgrade and clean activities            [/COLOR]
apt-daily.service                loaded    inactive dead    Daily apt download activities         

[/FONT]

[FONT=monospace][COLOR=#000000]$ systemctl list-timers | grep apt[/COLOR]
Thu 2020-05-07 01:49:51 EDT  6h left       Wed 2020-05-06 06:22:49 EDT  12h ago      [COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily.timer              [/COLOR][COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily.service[/COLOR]
Thu 2020-05-07 06:14:17 EDT  11h left      Wed 2020-05-06 06:05:49 EDT  12h ago      [COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily-upgrade.timer      [/COLOR][COLOR=#FF5454][B]apt[/B][/COLOR][COLOR=#000000]-daily-upgrade.s[/COLOR]ervice

[/FONT]

So I wonder if this core timer apt uses runs, and at some point packagekit/discover notices this later?

These services respect the apt-configs (the update script reads the set update interval with "apt-config shell UpdateInterval APT::Periodic::Update-Package-Lists")
Even though the timers trigger daily, it doesn't actually download the package lists every day if APT::Periodic::Update-Package-Lists is set to "7" (weekly)

[Don B. Cilly]

Hope you'll excuse me, I'm not trying to be critical or obnoxious, just slightly puzzled. You say:

I can disable the update notifications in the panel if I need to, but I'd actually like to be notified as a reminder to do it, so it'd not be ideal.

So I take it to mean that you'd like apt to check for updates every seven days... and then notify you if there are any updates?
Honestly, what are the chances that in seven days there won't be any? And at least a few of them "critical" (red icon)?
Even if you set it to daily, you're going to have the icon there more likely than not..

So though it does 'seem like a clear bug that the "every 7 days" is ignored' - it has been like that for... ages, I remember trying that, and failing, at least two years ago - I am puzzled as to what the use of it might be.
There's probably something I don't get - or get wrong.

That said, I tried systemctl list-timers | grep apt, noticed I had an apt-daily-upgrade.service due in a few minutes, and "watched" it :·)
Zero impact on CPUsage, network or disk activity, lasts less than 3 seconds. I even made a little video recording of it, if anyone doesn't believe me :··))
So, whatever it does, it doesn't seem to actually upgrade anything, it does not hog any resources, and... 'saul good, man.

[Ah. Forgot.] I do have 1.324s apt-daily-upgrade.service at boot.. But it not a big deal, is it :·)

[kubicle]

So I take it to mean that you'd like apt to check for updates every seven days... and then notify you if there are any updates?
Honestly, what are the chances that in seven days there won't be any? And at least a few of them "critical" (red icon)?
Even if you set it to daily, you're going to have the icon there more likely than not..

Maybe the notification is in this case used as a "reminder" to upgrade (like "oh, has it been a week since I upgraded, better get to it"). Not everyone upgrades their system daily.

That said, I tried systemctl list-timers | grep apt, noticed I had an apt-daily-upgrade.service due in a few minutes, and "watched" it :·)
Zero impact on CPUsage, network or disk activity, lasts less than 3 seconds. I even made a little video recording of it, if anyone doesn't believe me :··))
So, whatever it does, it doesn't seem to actually upgrade anything, it does not hog any resources, and... 'saul good, man.

Like I said, these services respect the apt-configuration, the ugrade service does nothing if you do not have unattended-upgades configured (even if the service is trigggered daily)

[jwrober]

FWIW, I would like to only update/upgrade my system once a month so if there is a way to get the check and impending notification to not show for 30 days that would be great.