** Description changed:
+ [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.
** Information type changed from Proprietary to Public
** Project changed: landscape => landscape-client
** Also affects: landscape-client (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1616116
Title:
Unrecoverable resyncs if DB is restored from backup
To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape-client/+bug/1616116/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
