Comment 3 for bug 1038167

Hi!

Since the beginning of this year, we are affected by this bug in our MultiKARL setup which is currently serving three customers. We see exactly the same traceback in our error monitor multiple times a day. However, it only shows up for one customer, especially during the morning hours, likely when people start working :-)

Fri Feb 8 09:53:30 2013 ERROR karl Error locking file
Error locking file /srv/multikarl/production/14/var/blob_cache/oxfam/259/.lock; pid=UNKNOWN

Traceback (most recent call last):
  File "/srv/multikarl/production/14/eggs/zc.lockfile-1.0.0-py2.6.egg/zc/lockfile/__init__.py", line 76, in __init__
    _lock_file(fp)
  File "/srv/multikarl/production/14/eggs/zc.lockfile-1.0.0-py2.6.egg/zc/lockfile/__init__.py", line 59, in _lock_file
    raise LockError("Couldn't lock %r" % file.name)
LockError: Couldn't lock '/srv/multikarl/production/14/var/blob_cache/oxfam/259/.lock'

What is interesting about this, is that when we see the locking error (per day), it always appears multiple times and is always about the same object (259 here) with exactly the same time stamp. In the example above, we see 6 occurrences with the time stamp 09:53:30.

As a note, we did not yet receive any customer complaints that anything is not working.

Since this bug has been filed in last August, I'm not sure which of the aspects that Chris is talking about in his description are still the case w.r.t our current setup. Chris knows our setup and involved processes quite good. So maybe he can try to re-evaluate his findings from August, relating them to our current setup and the fact that we now see this bug in our error monitor.

If it should turn out that there will be nothing we can do about this and that it will have no impact on user experience, we'd be happy if we could try to get this error being tracked at a lower log level (INFO or WARNING), just to avoid the generation of alarms.

Best regards,
Alex