-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File Is Loked #22591
Comments
Not sure if tht is our locking, or sabre, @DeepDiver1975 |
this happens if upload lasts longer than 1 hour? |
@hyperbaba then PHP is likely to have timed out and the lock is still in the database. You can try increasing the PHP timeout. Also to try: upgrade to 8.2.3 and then run cron.php. There's a cron job that clears stray locks. |
In your case it might be something different. @icewind1991 why are we locking chunk files ?!
|
@icewind1991 it looks like we are probably locking the wrong file name during upload. |
Like hyperbaba mentioned, this behavior happens for uploads longer then 1 hour. I tried to upload big files (up to 4GB) and as long as it is within one hour window upload is successful. I tried to upload smaller file (around 600MB with upload speed around 150kbps, thx to throttle command), the upload time was about 70-80 minutes. When the upload finished I got the message from duck client that the file is locked. This is the log from OC Fatal webdav - Exception: {"Message":"HTTP/1.1 423 "60mproba28800/FileAround600MB" is locked","Exception":"OCA\DAV\Connector\Sabre\Exception\FileLocked","Code":0,"Trace":"#0 /var/www/owncloud/apps/dav/lib/connector/sabre/directory.php(134): OCA\DAV\Connector\Sabre\File->put(Resource id #31)\n#1 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(1036): OCA\DAV\Connector\Sabre\Directory->createFile('FileAround600MB', Resource id #31)\n#2 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php(525): Sabre\DAV\Server->createFile('60mproba28800/F...', Resource id #31, NULL)\n#3 [internal function]: Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#4 /var/www/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#5 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(459): Sabre\Event\EventEmitter->emit('method:PUT', Array)\n#6 /var/www/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php(248): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#7 /var/www/owncloud/apps/dav/appinfo/v1/webdav.php(55): Sabre\DAV\Server->exec()\n#8 /var/www/owncloud/remote.php(138): require_once('/var/www/ownclo...')\n#9 {main}","File":"/var/www/owncloud/apps/dav/lib/connector/sabre/file.php","Line":174,"User":"dusan"} So, this only happens if the upload is longer then 1hr. On 8.2.2, file appeared on the server but as chunk (FileAround600MB.part) php values for input and execution time are set for 8 hrs in .htaccess file php_value max_input_time 28800 |
@Ma1kavian can you try increasing the lock ttl (https://github.com/owncloud/core/blob/stable8.2/lib/private/lock/abstractlockingprovider.php#L31) to verify if it caused by that |
@icewind1991 Upload was successful even if it lasted longer then 1 hour. Thanks a lot! I did exactly what you suggested, changed the ttl value from 3600 to 28800 in abstractlockingprovider.php. |
I can't reproduce this with 9.0 or 8.2, I changed the lock ttl to 1 minute and tweaked the speed throttle such that the upload takes ~2 minutes but upload always works fine |
@icewind1991 I just tried it on 8.2.2, also it has passed successfully. So, it worked for both 9.0, 8.2.2. Not sure if it is relevant, but we are using OpenStack's Object Store as backend storage. |
#23553 will automatically set the ttl to max_execution_time to prevent cases like this |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Actual behaviour
Hey! I saw that this is a common problem and it was fixes in 8.2.2 release. In my case, i guess it's not :/
Syncing larger files, i get this error. I used a test.txt with 500MB.
Tried to clean the oc_file_locks table manually too, nothing changed.
Any help with this?
Server configuration
Operating system: Ubuntu Linux
Web server:
Database: MySQL
PHP version: 5.5
ownCloud version: 8.2.2
Updated from an older ownCloud or fresh install: fresh install
The content of config/config.php:
Are you using external storage, if yes which one: NO
Are you using encryption: NO
ownCloud log (data/owncloud.log)
{"reqId":"VsuaoLx5OQoADEoH@IMAAAJB","remoteAddr":"89.155.20.211","app":"webdav","message":"Exception: {"Message":"HTTP\/1.1 423 \"Office\/test.txt-chunking-2492390319-101-100\" is locked","Exception":"OC\Connector\Sabre\Exception\FileLocked","Code":0,"Trace":"#0 \/home\/nunoarmada\/public_html\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(1053): OC\Connector\Sabre\Directory->createFile('test.txt-chunki...', Resource id #111)\n#1 \/home\/nunoarmada\/public_html\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/CorePlugin.php(513): Sabre\DAV\Server->createFile('Office\/test.txt...', Resource id #111, NULL)\n#2 [internal function]: Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#3 \/home\/nunoarmada\/public_html\/owncloud\/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#4 \/home\/nunoarmada\/public_html\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(469): Sabre\Event\EventEmitter->emit('method:PUT', Array)\n#5 \/home\/nunoarmada\/public_html\/owncloud\/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(254): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response))\n#6 \/home\/nunoarmada\/public_html\/owncloud\/apps\/files\/appinfo\/remote.php(56): Sabre\DAV\Server->exec()\n#7 \/home\/nunoarmada\/public_html\/owncloud\/remote.php(137): require_once('\/home\/nunoarmad...')\n#8 {main}","File":"\/home\/nunoarmada\/public_html\/owncloud\/lib\/private\/connector\/sabre\/directory.php","Line":121}","level":4,"time":"2016-02-22T23:32:48+00:00"}
The text was updated successfully, but these errors were encountered: