Upgrade 9.1.6.2 -> 10.0.2.1 null cache when moving avatars outside home (fed shares) #28763
Comments
|
I disable app files_sharing and it work now.... |
|
If active the app, error via Web: |
|
Can you try I wonder if the "root" storage entry is broken in some way. |
|
Also check if the folder "data/avatars" exists now, considering that the avatar migration failed. cc @butonic |
Folder data/avatars exists... |
|
This is normal? An entry in oc_filecache without patch: |
|
the root entry has no path, yes this is normal. |
|
Annotation. When you disable the files_sharing app you can complete the upgrade correctly. But when you re-enable it (with the app updated) it still fails with the same error message. |
|
@XHAGBARD
So I checked all remote shares in the database: I also removed the shares to the storage with invalid certificates from the table oc_share. Maybe in some future release an invalid SSL certificate of a remote share does not break owncloud but disables the share automatically and puts a warning in the logs (or to the user). |
|
@tomneedham another case of cert issue blocking the upgrade ^ |
|
I also have the same Upgrade issue except that i am upgrading from 9.1.6.2 to 10.0.3.3. It works only when disabling the files_sharing app, but then we cannot access the shared files |
|
I issued the new ticket here: #29209 if this is not neccessary, please close it |
Steps to reproduce the stack trace (not upgrade)
That should be enough to debug this. |
|
Both A and B should be OC 9.1.6.2? By the way just to clarify, i do not use external storage |
|
This is happening because the storage class for the federated share has a programming mistake: the constructor is not supposed to initiate any connection to the remote. The connection needs to be initiated only once an actual access is requested. The error is happening here: https://github.com/owncloud/core/blob/v10.0.3/apps/files_sharing/lib/External/Storage.php#L82. This code is trying to find out the remote endpoints by connecting to the remote's "ocs-provider" endpoint. This is happening too early. The sad thing about this is that not doing this call makes it impossible to have a value for the "root". Now we could try to catch the exception in question. We're already catching ClientException and ConnectException. Unfortunately for this one case, Guzzle throws a |
|
There are two fixes to work on:
The mitigation already makes the exception disappear for me. |
|
@pep29 in my case both are 10.0.3. My reproduction case is not related to an upgrade, it's just a different way of reproducing the same core issue. I expect that the fixes will also help repairing the upgrades. @pep29 If you still have a setup where you can reproduce this, can you try with the following patch before upgrading: #29210 (download as patch: https://patch-diff.githubusercontent.com/raw/owncloud/core/pull/29210.patch) |
|
@pep29 in your case you need to apply the patch on the 10.0.3 code, just before running |
|
I do not use external storage, which is why the "oc_share_external" is empty. Can you please tell me more about the Mitigate, i could try it, I mean how exactly? Since i upgraded after disabling the files_sharing app, i guess it is already to late to use the patch #29210 |
|
@PVince81 Unfortunately the patch #29210 does not help me, i still get stuck in "Move user avatars outside the homes to the new location" step when the files_sharing is enabled 2017-10-11T15:55:48+00:00 Set log level to debug |
|
In the log file, i got this |
|
@pep29 thanks for testing. Seems the stack trace is gone. If it hangs, I suspect it might be trying to connect to federated share servers which are not available and is waiting for a connection timeout. If that's the case, this would fall under the third category to fix: "Prevent the constructor of the federated share external storage class to do any remote connections" |
|
@PVince81 It just hang there till it timeout. Since i do not use external storage, can i get ride of it? Another thing, i use two different owncloud for two different websites A and B, the upgrade on B went smootless, however it not that heavily used as A. Could be the huge amount of Data on A be a problem? |
|
@pep29 but you are using federated shares or some of your users do ? Federated shares internally work like external storages. If there aren't that many, you could check the contents of the "oc_share_external" table. I suspect that maybe some of the domains in that list are not reacahable any more. The quantity of data in the ownClouds should not matter for this one specific spot of the upgrade. |
|
@PVince81 the "oc_share_external" table is indeed empty for both mentioned site A and B |
|
@pep29 uh oh... ok, so it means it's yet another bug. It is possible that my patch above mitigated it a bit. If it's neither external storage nor incoming federated shares, then it can likely only be somewhat broken local shares. @pep29 mind filling the issue template and posting it as a comment here ? I'd like to see what apps you have enabled for more clues. |
|
@PVince81 We indeed have some problems with local share (many folder are for some reasons duplicated with the extra [2]), there also many tickets about this duplicate issue. here is a list of the used apps (i also use files_sharing, but for now it is disabled)
Here #29209 for the other infos |
|
PR for lazily connecting to federated shares, should improve update speed: #29275 (it shouldn't hang for such a long time!) |
|
Two tasks from #28763 (comment) done. Remaining one is about catching RingException |
|
I have retested the 9.1->10.0.4beta2 upgrade scenario. With the two fixes in place, there is no more leaking of RingException and the upgrade properly goes through. |
|
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. |
Steps to reproduce
Expected behaviour
No upgrade finish
Actual behaviour
Tell us what happens instead
Server configuration
Operating system: Centos 7.3.1611
Web server: httpd
Database: Percona Server 5.7.18-16
PHP version: 7.0.22
ownCloud version: 10.0.2.1
Updated from an older ownCloud or fresh install: 9.1.6.2
Where did you install ownCloud from: /var/www/html/owncloud
Signing status (ownCloud 9.0 and above):
The content of config/config.php:
List of activated apps:
Are you using encryption: yes
ownCloud log
The text was updated successfully, but these errors were encountered: