update-notifier ignores update-manager's settings

Bug #1817559 reported by Ivan Zorin on 2019-02-25
4
This bug affects 1 person
Affects Status Importance Assigned to Milestone
software-properties (Ubuntu)
Low
Unassigned

Bug Description

> 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu

$ lsb_release -rd
Description: Ubuntu 16.04.6 LTS
Release: 16.04

> 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center

$ apt-cache policy update-manager
update-manager:
  Installed: 1:16.04.15
  Candidate: 1:16.04.15
  Version table:
 *** 1:16.04.15 500
        500 https://mirror.one.com/ubuntu xenial-updates/main amd64 Packages
        500 https://mirror.one.com/ubuntu xenial-updates/main i386 Packages
        100 /var/lib/dpkg/status
     1:16.04.12 500
        500 https://mirror.one.com/ubuntu xenial-security/main amd64 Packages
        500 https://mirror.one.com/ubuntu xenial-security/main i386 Packages
     1:16.04.3 500
        500 https://mirror.one.com/ubuntu xenial/main amd64 Packages
        500 https://mirror.one.com/ubuntu xenial/main i386 Packages

----

Steps to reproduce:

- Run `update-manager' manually, via `update-manager' from a terminal for example
- Press "Settings..." button
- Configure the following settings to hide all update-manager's pop-ups respectively:

Automatically check for updates: Never
When there are security updates: <blank>
When there are other updates: Display every two weeks
Notify me of a new Ubuntu version: Never

- Close settings
- Exit `update-manager'

----
Expected behaviour:

- update-manager won't be checking any updates at all
- but even if there are some "other updates" then it must be displayed not more often than "every two weeks"

----
Actual behaviour:

- update-manager checks for updates from time to time by itself
- update-manager shows notifications *all* *the* *time*: every single day and much more times per day than even twice
- update-manager keeps to show notifications even if it has been seen & closed manually (just because there wasn't time for maintenance window currently, for example)

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: update-manager 1:16.04.15
ProcVersionSignature: Ubuntu 4.4.0-143.169-generic 4.4.170
Uname: Linux 4.4.0-143-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Feb 25 16:32:29 2019
GsettingsChanges:
 b'com.ubuntu.update-manager' b'show-details' b'true'
 b'com.ubuntu.update-manager' b'window-height' b'365'
 b'com.ubuntu.update-manager' b'first-run' b'false'
 b'com.ubuntu.update-manager' b'window-width' b'303'
 b'com.ubuntu.update-manager' b'launch-time' b'int64 1551101458'
InstallationDate: Installed on 2016-07-19 (951 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
PackageArchitecture: all
SourcePackage: update-manager
UpgradeStatus: No upgrade log present (probably fresh install)

Ivan Zorin (iaz) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. Could you take a screenshot/photo from one of those notifications? What desktop environment do you use?

Changed in update-manager (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Ivan Zorin (iaz) wrote :

> Could you take a screenshot/photo from one of those notifications?

I will once I will get some (now my system is updated currently so it doesn't have unattended updates, therefore I'm not getting any notifications about available updates for now).

But in general it looks just like this: https://www.omgubuntu.co.uk/wp-content/uploads/2013/01/software-updater-in-raring.jpg

> What desktop environment do you use?

>> CurrentDesktop: Unity

And here is a few additional details:

$ unity --version
unity 7.4.5

$ apt-cache policy unity
unity:
  Installed: 7.4.5+16.04.20180221-0ubuntu1
  Candidate: 7.4.5+16.04.20180221-0ubuntu1
  Version table:
 *** 7.4.5+16.04.20180221-0ubuntu1 500
        500 https://mirror.one.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     7.4.0+16.04.20160415-0ubuntu1 500
        500 https://mirror.one.com/ubuntu xenial/main amd64 Packages

Sebastien Bacher (seb128) wrote :

The screenshot you are referencing is not a notification but update-manager itself...

Ivan Zorin (iaz) wrote :

> The screenshot you are referencing is not a notification but update-manager itself...

Yes, I know, exactly. That's why I did report on `update-manager' package while I was preparing this current bug report:

> Package: update-manager 1:16.04.15

And I'm getting related notification (not exactly the same one obviously since each time there are different list of packages for update but similar: https://www.omgubuntu.co.uk/wp-content/uploads/2013/01/software-updater-in-raring.jpg) each time when there are some updates available *despite* the fact that all the auto checks have been disabled through settings which are provided by the update-manager's interface (which you can see in my attachment here: https://launchpadlibrarian.net/412749054/update_manager_settings.png

Sebastien Bacher (seb128) wrote :

What do you call 'notification', the update-manager dialog itself?
A notification is something like that, https://i.stack.imgur.com/HGjE9.png

Sebastien Bacher (seb128) wrote :

None of those screenshot show a notification...

Changed in update-manager (Ubuntu):
status: Incomplete → New
Ivan Zorin (iaz) wrote :

>> Could you take a screenshot/photo from one of those notifications?

> I will once I will get some (now my system is updated currently so it doesn't have unattended updates, therefore I'm not getting any notifications about available updates for now).

Here, just as I promised.
It has been displayed today.
See the attachment.

Ivan Zorin (iaz) wrote :

And here is the *current* settings which *have been active* while I've got that dialog window ( on the previous attachment: https://launchpadlibrarian.net/413195181/update-manager-screenshot-with-ignored-settings.png ) with notification about updates, in the attachment.

In fact, while I've got that window popped-up, the (probably?) related systemd services & timers *have been disabled* (by `mask') as well, manually, by me, a couple of days ago. Here is the current state of them:

$ sudo systemctl status apt-daily.service
● apt-daily.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)
$ sudo systemctl status apt-daily.timer
● apt-daily.timer
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)
Warning: apt-daily.timer changed on disk. Run 'systemctl daemon-reload' to reload units.
$ sudo systemctl status apt-daily-upgrade.service
● apt-daily-upgrade.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)
$ sudo systemctl status apt-daily-upgrade.timer
● apt-daily-upgrade.timer
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)
Warning: apt-daily-upgrade.timer changed on disk. Run 'systemctl daemon-reload' to reload units.
$

I didn't have time to learn what and how they do so I just disable them (by `sudo systemctl mask') since I prefer to control update maintenance completely by myself, when it's convenient for my time and not PC's time. I thought that it should be enough but I was really surprised that it didn't do the trick. The next step will be wiping everything which is related to apt/update from /etc/cron.* directories.

P.S. I really don't and just can't understand why `Software Updater' has nearly the same `design' and `usability experience' just like Windows 10 update service nowadays, with a complete ignore of user settings, preferences, focus and time.

Sebastien Bacher (seb128) wrote :

Ok, so what you call 'notification' seems to be in fact the application itself opening (you still didn't include any screenshot showing a notification so let's assume it's a vocabulary error)

could you
$ killall update-notifier
$ update-notifier --debug-updates

ANd copy the log there?

Ivan Zorin (iaz) wrote :

> what you call 'notification' seems to be in fact the application itself opening (you still didn't include any screenshot showing a notification so let's assume it's a vocabulary error)

If it's not about notifying user about updates by showing window with related info, why it's called `update-*notifier*' then?

> copy the log there

Here you go:

$ killall update-notifier
$ update-notifier --debug-updates
(update-notifier:6221): update-DEBUG: update_check()
(update-notifier:6221): update-DEBUG: /usr/lib/update-notifier/apt-check returned 6 (security: 6)
(update-notifier:6221): update-DEBUG: is_package_system_locked: /usr/lib/update-notifier/package-system-lockedreturned 0
(update-notifier:6221): update-DEBUG: interval_days: 14
(update-notifier:6221): update-DEBUG: last_launch: 1551322900 (Thu Feb 28 06:01:40 2019
)
(update-notifier:6221): update-DEBUG: security updates, auto-launching
/usr/bin/update-manager:28: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/lib/python3/dist-packages/UpdateManager/UnitySupport.py:29: PyGIWarning: Dbusmenu was imported without specifying a version first. Use gi.require_version('Dbusmenu', '0.4') before import to ensure that the right version gets loaded.
  from gi.repository import Dbusmenu, Unity
/usr/lib/python3/dist-packages/UpdateManager/UnitySupport.py:29: PyGIWarning: Unity was imported without specifying a version first. Use gi.require_version('Unity', '7.0') before import to ensure that the right version gets loaded.
  from gi.repository import Dbusmenu, Unity

So, my humble understanding is that, according to current user' settings, this value:

> interval_days: 14

must be 0 or -1 or anything other value (like 36500 - I guess that it will be enough) which would make `update-manager' and `update-notifier' both inactive.

Should I mark this report as invalid now and create a new one related to `update-notifier' package at this time?

Sebastien Bacher (seb128) wrote :

> Should I mark this report as invalid now and create a new one related to `update-notifier' package at this time?

That's not needed, the bug can be reassigned to another component, doing that now

affects: update-manager (Ubuntu) → update-notifier (Ubuntu)
Sebastien Bacher (seb128) wrote :

Some comments

* the log has 'update-DEBUG: security updates, auto-launching', so it seems update-notifier is starting update-manager because there are security updates pending

* the settings are about 'automatic refreshing the apt packaging indexes', not about when the UI opens when there are pending updates listed

* the issue might come from the interaction with unattendee-upgrade

Ivan Zorin (iaz) wrote :

$ apt-cache policy update-notifier
update-notifier:
  Installed: 3.168.10
  Candidate: 3.168.10
  Version table:
 *** 3.168.10 500
        500 https://mirror.one.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.168.7 500
        500 https://mirror.one.com/ubuntu xenial-security/main amd64 Packages
     3.168 500
        500 https://mirror.one.com/ubuntu xenial/main amd64 Packages

summary: - update-manager ignores its own settings completely
+ update-notifier ignores update-manager's settings
Ivan Zorin (iaz) wrote :

Now it's becoming interesting and really confusing. I had some time to dig through a little. Looks like that update-notifier can be configured through gsettings/dconf-editor (see the related attached screenshot). So, update-manager has nothing to do with notifications but it's update-notifier which runs update-manager.

There is no way to configure update-notifier through it's own GUI and at the same time update-manager's settings are ignored by update-notifier.

Ivan Zorin (iaz) wrote :

The trick with setting zero or negative number for interval_days won't be working since it will be meaning to trigger updater right away (see the attached screenshot with the related setting) - here is the related code (it's still the same in 18.10/Cosmic):

https://git.launchpad.net/ubuntu/+source/update-notifier/tree/src/update.c?h=ubuntu/cosmic#n510

// check if the auto launch interval is over and its
// time to launch again and if the dpkg lock is currently
// not taken
static gboolean
auto_launch_now (TrayApplet *ta)
{
...
   if (interval_days <= 0)
      return TRUE;
...
}

Setting the large number for interval_days won't be working all the time either because there is "bypass" for security updates:

   if (auto_launch_security_now(priv, now, last_launch))
      return TRUE;

There is another one setting for update-notifier through gsettings/dconf ( see the previous screenshot here - https://launchpadlibrarian.net/413216259/software_updater_notifier_notifications.png ): no-show-notifications/SETTINGS_KEY_NO_UPDATE_NOTIFICATIONS (which has nothing to do with notifications about updates, I got it). But, as far as I understand, according even to current source code, it doesn't do much since:
- it is checked in the last turn when main routine (related to check/show info about updates) will be completed already
- even if it will be set as true, the related function will return TRUE (not FALSE) anyway via pass-thru further execution

https://git.launchpad.net/ubuntu/+source/update-notifier/tree/src/update.c?h=ubuntu/cosmic#n654

gboolean
update_check (TrayApplet *ta)
{
...
   // the user does not no notification messages
   if(g_settings_get_boolean(ta->un->settings,
                             SETTINGS_KEY_NO_UPDATE_NOTIFICATIONS))
      return TRUE;
...
   ...
   return TRUE;
}

// yes, the user does not no notification messages, exactly, but seems that the code doesn't care about it too much :)

Once again, I may be wrong (should double check the routines behind g_settings_*), but if it's the reason for calling `update-manager' and if g_settings_get_boolean(ta->un->settings,SETTINGS_KEY_NO_UPDATE_NOTIFICATIONS) returns TRUE when SETTINGS_KEY_NO_UPDATE_NOTIFICATIONS is set then there should be FALSE on return. Something like that:

   if(g_settings_get_boolean(ta->un->settings,
                             SETTINGS_KEY_NO_UPDATE_NOTIFICATIONS))
      return FALSE;

And the check itself should be much early inside of `gboolean update_check (TrayApplet *ta)', before any other checks. In case if it's really the right direction for the issue.

Ivan Zorin (iaz) wrote :

> (see the attached screenshot with the related setting)

Added the missed screenshot.

Steve Langasek (vorlon) wrote :

Changing the setting for how often to automatically check for updates to 'Never' instructs the system not to automatically run 'apt-get update' to check for updates. It does not invalidate the results of a previous 'apt-get update' run which has already found that there are updates waiting to be applied.

If there are already security updates waiting to be applied, the behavior when "Automatically check for updates" is set to "Never" is effectively undefined. This is the "When there are security updates: <blank>" - the option is greyed out but in practice what this actually means is that the behavior is the same as "Display immediately".

I am inclined to argue that this is a bug in software-properties, which should *show* that any available security updates will still result in a prompt, not a bug in update-notifier for doing the prompting. The difference between the two, after all, is a one-time pop-up that is easily resolved by applying the security updates.

Making it easier to ignore security updates than it already is would be an antifeature.

affects: update-notifier (Ubuntu) → software-properties (Ubuntu)
Matthew Paul Thomas (mpt) wrote :

Ubuntu’s update prompt is a notification in the ordinary English sense of the word. <https://wiki.ubuntu.com/NotificationDesignGuidelines#Normal_window> So I guess the dconf keys predate update-notifier’s change from using FDo notifications to launching update-manager, but I don’t think that requires their name or description to be changed. (It is perverse, though, to have a boolean setting whose name starts with “no-”.)

I think the bug here is that setting “Automatically check for updates:” to “Never” has caused “When there are security updates:” to become blank+disabled, suggesting that there will be no prompts when really there will be. This doesn’t happen in 14.04, so I guess someone changed it when they realized the current menu options are only relevant to automatic checks. But besides the case where updates became known before you switched to “Never”, there’s a much more likely case where security updates might be known without automatic checks: if you did a manual check but then didn’t install them.

So, I guess the menu should instead contain options for when to remind you about known security updates that aren’t installed yet, no matter how that happened. Anyone who’s seen a billboard or digital sign defaced by a giant Windows update prompt might think “Never” should be one of the options, but I’ll defer to Steve that it shouldn’t be. (I guess we’d say that kind of thing should use Ubuntu Core instead.)

Changed in software-properties (Ubuntu):
assignee: nobody → Matthew Paul Thomas (mpt)
status: New → In Progress
Matthew Paul Thomas (mpt) wrote :

Specification updated <https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=230&rev1=229>: ‘Whenever “Automatically check for updates:” is set to “Never” (so any security updates are known from manual or previous checks), the “When there are security updates:” menu should consist of options “Remind me daily” (the default), “Remind me every two days”, “Remind me weekly”, and “Remind me every two weeks”. Whenever “Automatically check for updates:” is set to anything other than “Never”, the “When there are security updates:” menu should instead consist of options “Display immediately” (the default) and “Install automatically”.’

Changed in software-properties (Ubuntu):
assignee: Matthew Paul Thomas (mpt) → nobody
status: In Progress → Triaged
To post a comment you must log in.