Package manager is failing with "no such table: task"

Bug #416629 reported by Thomas Herve on 2009-08-20
4
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Landscape Client
Medium
Thomas Herve

Bug Description

Got the following traceback a couple of times while testing on EC2:

  File "/usr/lib/python2.5/site-packages/landscape/plugin.py", line 82, in dispatch_message
    return handler(message)
  File "/usr/lib/python2.5/site-packages/landscape/manager/packagemanager.py", line 39, in _enqueue_message_as_changer_task
    self._package_store.add_task("changer", message)
  File "/usr/lib/python2.5/site-packages/landscape/package/store.py", line 34, in inner
    result = method(self, cursor, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/landscape/package/store.py", line 280, in add_task
    "VALUES (?,?,?)", (queue, time.time(), buffer(data)))
OperationalError: no such table: task

It only happens when scheduling a package activity shortly after startup. The package activity related stays in "Delivered" forever.

Thomas Herve (therve) on 2009-08-20
Changed in landscape-client:
importance: Undecided → Medium
milestone: none → 1.3.5
description: updated
Andreas Hasenack (ahasenack) wrote :

Got the error in another place. I used an initial script and the hardy large ami.

==> /var/log/landscape/monitor.log <==
2009-08-20 21:17:00,864 ERROR [MainThread] Error running event handler landscape.monitor.packagemonitor.PackageMonitor._resynchronize() for event type 'resynchronize' with args () {}.
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/landscape/reactor.py", line 78, in fire
    results.append(handler(*args, **kwargs))
  File "/usr/lib/python2.5/site-packages/landscape/monitor/packagemonitor.py", line 85, in _resynchronize
    {"type" : "resynchronize"})
  File "/usr/lib/python2.5/site-packages/landscape/package/store.py", line 34, in inner
    result = method(self, cursor, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/landscape/package/store.py", line 280, in add_task
    "VALUES (?,?,?)", (queue, time.time(), buffer(data)))
OperationalError: no such table: task

Thomas Herve (therve) wrote :

I've found the problem: it's a bug in sqlite itself (either the bindings or sqlite). See the attached script: running "rm /tmp/1; python 1.py & python 1.py &" a couple of times should reproduce the bug quite easily (the first select fails in one of the process). Uncommenting the previous select solves the bug.

Thomas Herve (therve) wrote :

This is ready to review in the attached branch. Running a new query after the table creation seems to fix the problem, and I can't reproduce the bug anymore.

Changed in landscape-client:
assignee: nobody → Thomas Herve (therve)
status: New → In Progress
tags: added: review
Free Ekanayaka (free.ekanayaka) wrote :

Very good catch.

Just a minor non-blocking comment. I'm wondering if for extra-safety we should perform the same dummy select on the other tables as well, even though that is probably not strictly necessary as they are not used by the package manager process.

+1!

Sidnei da Silva (sidnei) wrote :

[1] I find it odd that one of the new blocks catches both (OperationalError, DatabaseError), and the other catches only OperationalError. Shouldn't they both catch the same exception.

[2] Additionally, a try: except: else is being used, which means that if by any chance a different exception is raised other than the ones that are being catched the cursor will not be closed. I would change that to try: (try: except: pass) finally: cursor.close() instead.

+1 with those changes done, or a good justification. :)

tags: removed: review
Thomas Herve (therve) wrote :

Sidnei: about your [1], the code checks for an invalid database file, and handles this case (as no functionality is broken). So I have to keep them.

Merged in r140.

Changed in landscape-client:
status: In Progress → Fix Committed
tags: added: needs-testing
Changed in landscape-client:
status: Fix Committed → Fix Released
Jamu Kakar (jkakar) on 2009-10-08
tags: added: karmic-issue
Changed in landscape-client:
status: Fix Released → In Progress
assignee: Thomas Herve (therve) → Free Ekanayaka (free.ekanayaka)
Free Ekanayaka (free.ekanayaka) wrote :

Unfortunately the bug is still there. I've opted for a more radical approach, and made the PackageStore class lazy, that means it creates the connection only when some queries are actually being requested.

I real-world tested the attached branch and it seems to work, as times at which the packagemanager and the packagemonitor handle their messages are typically not close (while the the times at which they register themselves as plugins are).

I think we should push this fix to the various AMIs, as it is particularly relevant for cloud instances.

tags: added: review
removed: karmic-issue needs-testing
tags: added: fix-it-friday
Jamu Kakar (jkakar) wrote :

I've created bug #465846 to track the new issue Free has brought up.
Please direct comments and reviews there.

tags: removed: fix-it-friday review
Changed in landscape-client:
assignee: Free Ekanayaka (free.ekanayaka) → Thomas Herve (therve)
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments