Lock files issues - 65K entries in table oc_file_locks

Hi,

oc 9.1.1 - fresh install, smoothly running since 4 months - php 5.6.30 - MySQL 5.5.44

We have a number of users with red cross on the ownCloud client (2.3.1). Reason : Error transferring https..... Server replied : lock.

So we went and checked the OC DB and found out that the table oc_file_locks has more than 65K entries. Most of them have a lock of "0" but a little more than a dozen have a value between -1 and 15.

Is that normal, should we delete all entries or should they all be 0??? Isn't this supposed to be tackled by the cron job? It is set to Ajax for now.

Thanks for any hints

olco

Hi,

this is quite outdated as you can see at [1] and shouldn't be used on a productive environment.

This is most likely the issue here, for productive systems with more than a single user its strongly advised to use the systems cron background jobs. See [2] for some background info.

[1] https://owncloud.org/changelog/#latest9.1

[2]

Thanks,

We will try to plan a upgrade to 9.1.5 during the weekend and move off Ajax cron.

Would you recommend upgrading all versions between 9.1.1 and 9.1.5 ? Or go direct to 9.1.5?

BR,

olco

Its highly recommended to not update to a previous release in between to avoid bugs (especially update bugs) in that older releases.

So a correct update path from 9.1.1 to 9.1.5 would be to update directly to 9.1.5 leaving out 9.1.2 to 9.1.4.

Only if you want to upgrade to the next major release (e.g. from 9.0.x to 9.1.x) you should do something like:

9.0.5 -> 9.0.9 -> 9.1.5

and not jump from

9.0.5 directly to 9.1.5

Yes, that what we were thinking of. Thanks for confirming it.

olco

Hi,

I can’t see that anyone actually answered olco’s question…

"…the table oc_file_locks has more than 65K entries. Most of them have a lock of “0” but a little more than a dozen have a value between -1 and 15.

_Is that normal, should we delete all entries or should they all be 0??? Isn’t this supposed to be tackled by the cron job? It is set to Ajax for now"

We have the much the same (on v 10.0.6) - 30K entries most with lock=0 and a little more than a dozen have a value between -1 and 15

I know 10.0.6 isn’t the latest, but previous discussion was all about v9…

Someone must know how the lock table should look. Should there be an entry for every file or should the table be empty except for locked files?

Thanks; David

I took a chance anyway…

I left all the entries in the table but set all “lock” fields that were non-zero to zero.

That seemed to unlock the files we had a problem with - the files could be deleted, which solved our immediate problem.

But I’d still like to know how the table should look normally.

/David

Hey,

i did the following query in my ownCloud 10.0.9 (running system cron) database:

SELECT COUNT(*) FROM oc_file_locks;

which returned:

+----------+
| COUNT(*) |
+----------+
|        0 |
+----------+

Ha - so the table should normally be empty.

I’ll try removing the entries by hand and see what happens :slight_smile:

Thanks tom42!

Hey, i would to the following (if not already done):

  1. Update to 10.0.9 or the upcoming 10.0.10
  2. Configure the systems cron
  3. Configure redis for file locking
  4. Clean up the oc_file_clock table: File is locked - how to unlock

I have 1-3 on my system, maybe this could also explain why my table is empty?

We are stuck at 10.0.6 for the moment since our host provider blocks PHP routines used by the web-based upgrader (and we don’t have ssh access).

As soon as we find time to move to a new host I’ll double check this again.

Thanks for the information!