group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1616116@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package landscape-client - 18.01-0ubuntu3.2

---------------
landscape-client (18.01-0ubuntu3.2) bionic; urgency=medium

  * debian/patches/nutanix-kvm.patch: Update vm_info.py to include Nutanix
    hypervisor. (LP: #1788219)
  * Fixes for release-upgrade:
    - debian/patches/release-upgrade-success.patch: Enable landscape-client to
      survive trusty upgrade. (LP: #1670291)
    - debian/patches/post-upgrade-reboot.patch: Force reboot operation in
      case systemd fails. (LP: #1670291)
  * debian/patches/unicode-tags-script.patch: Permit environments
    containing unicode chars for script execution. (LP: #1765518)
  * debian/patches/1616116-resync-loop.patch:
    Clear hash id database on package resync. (LP: #1616116)

 -- Simon Poirier <simon.poirier@xxxxxxxxxxxxx>  Tue, 27 Nov 2018
09:24:22 -0500

** Changed in: landscape-client (Ubuntu Bionic)
       Status: Fix Committed => Fix Released

** Changed in: landscape-client (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1616116

Title:
  Unrecoverable resyncs if DB is restored from backup

Status in Landscape Client:
  Fix Committed
Status in landscape-client package in Ubuntu:
  Fix Released
Status in landscape-client source package in Trusty:
  Fix Released
Status in landscape-client source package in Xenial:
  Fix Released
Status in landscape-client source package in Bionic:
  Fix Released
Status in landscape-client source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * In some cases generally involving backups/restore, client would get
     inconsistent package data and keep that data upon resync, thus getting
     stuck in a resync loop. This usually gets noticed through the stress
     it adds on the server and though logs which grow abnormally.

  [Test Case]

    * deploy landscape-server quickstart from ppa:landscape/18.03
    * register client against server. wait for package info
    * pg_dumpall
    * add a repo and wait for new package to show on in landscape.
    * restore the postgres backup.
    * run ./scripts/hash_id_databases.sh from the server to complete
      the restore. 
    * trigger a package install from the new repo to create some package
      info to update
    * client should resync once then will re-fetch hash on the next run.

  [Regression Potential]

   * Modified code is used only during resync operations and removes
     cached data when the client state is deemed inconsistent.

   * In the unlikely event the code is called outside of the expected
     cases, the end result would be limited to the package-monitor 
     having to re-download the hash-id databases, which shouldn't
     cause issues as that is the behaviour at client registration.

  [Other Info]
   
   * Other cases than server restores have been noticed to generate the
     bug but they are far less common.

  [Original description]

  Landscape with live clients cannot handle a DB restore to a point in
  the past.

  The scenario is Landscape running as usual, with live clients,
  restoring to a DB backup taken in the past. After the service ir
  brought up again with this data, clients will start resyncing and
  becoming wedged with all sorts of tracebacks on the message server.

  I left such a scenario running overnight, hoping that eventually the
  resyncs would settle down and everything recover, but that didn't
  happen. The resyncs continued, in the packages scope.

  An interesting one in particular was this:
  Aug 22 21:46:26 message-server-2 ERR  Error handling message 'operation-result' for computer 104: {'status': 6, 'timestamp': 1471901963, 'result-text': u'Mon Aug 22 21:39:23 UTC 2016\n', 'api': '3.3', 'operation-id': 533, 'type': 'operation-result'}#012Traceback (most recent call last):#012  File "/opt/canonical/landscape/canonical/landscape/message/apis.py", line 358, in _process_messages#012    self.handle(message["type"], message)#012  File "/opt/canonical/landscape/canonical/message/api.py", line 66, in handle#012    return handler(type, body)#012  File "/opt/canonical/landscape/canonical/message/handler.py", line 30, in __call__#012    return function(self.message_api, type, body)#012  File "/opt/canonical/landscape/canonical/lib/arguments.py", line 79, in replacement#012    return original(*new_args, **new_kwargs)#012  File "/opt/canonical/landscape/canonical/landscape/message/handlers/activity.py", line 32, in handle_activity_result#012    activity.succeed(code=result_code, text=result_text)#012AttributeError: 'NoneType' object has no attribute 'succeed'

  That was about an activity that had been delivered already, but did
  not exist in the restored DB.

To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape-client/+bug/1616116/+subscriptions