Upgrade 9.0.3.2 -> 9.1.1.3 (CentOS) - DiscoverManager not found #26297
Comments
PVince81
changed the title
|
@stephan-l can you check whether the file "apps/federatedfilesharing/lib/DiscoveryManager.php" exists after the update ? From what I can see it exists in the tarball. |
|
Yes it is present after the upgrade: |
|
Hmmm... so if the update code didn't find the file while running it could be that PHP CLI had old code cached and didn't load the new one ? I heard about APC (or APCu) code caching that might need clearing. |
|
@PVince81 Yes, such caching issues where reported from time to time. Thats why the manual upgrade steps are containing the info to stop and start the webserver: https://doc.owncloud.org/server/9.1/admin_manual/maintenance/manual_upgrade.html There are a few issues about that:
|
|
I tried it twice. Both times I restarted the whole machine first. The first time it got stuck at the same place. The second time it continued until Update 3rd-party app and stopped due missing LDAP. But that's my fault. The clone I'm testing on got no access to it. So I got no idea why it is working the second time. I just left the machine off for some days before. May this voided some caches? Reproducing this isn't that easy since every upgrade takes 1.5 hours... |
|
Today I gave it another try. Caching shouldn't be a problem anyway since it is not used for CLI tasks. From my last try I assume it crashed because of missing LDAP before reaching the problimatic code. The current log: |
|
Still present in 9.1.2-1.1 |
|
Got the same issue here while trying to upgrade from 9.0.7 to 9.1.3. |
|
@PVince81 What information do we need here? 00006823 |
|
Here's the upgrade CLI output: ownCloud or one of the apps require upgrade - only a limited number of commands are available |
|
Autoloader expert required @DeepDiver1975 @PhilippSchaffrath @butonic |
|
@SergioBertolinSG can you help reproducing this ? Maybe try on CentOS... @michaelstingl a full issue report would be useful, especially the parts about how to reproduce it and what distro... If there are common aspects between the reports then it can provide clues how to reproduce it. For example if all report that the issue is on CentOS with distro packages, then it's likely related to that... |
|
It's openSUSE here. No packages. I've used the oC Enterprise tar from customer.owncloud.com. |
|
openSUSE Tumbleweed here, my steps:
Works for me. php5-5.6.28-1.1.x86_64 |
|
Hello, upgrades 9.0.7->9.1.3 using centos both tarball and packages worked correctly. Perhaps it requires federated shares or tags assigned to a federated shared/recieved file? |
|
So does this mean, that this bug was resolved in 9.1.3 @SergioBertolinSG ? Or does it still persists regarding your attached log? |
|
@stephan-l No, sorry didn't mean that. Those logs are from your failure and the other one. I couldn't reproduce with a basic installation, so I guess it requires to have federated shares (shared or received) before upgrade. |
|
I have recently tried what happens if I delete my whole LDAP config before upgrading to 9.1.3. Without that it worked for me too. So the problem clearly belongs to the database entries I think. Maybe users, shares or federated shares. I have several thousands of them in my production system. |
|
The CLI output says the following: The step where the crash happens without deleting LDAP config seems to be this one: "repair info: 129 tags of deleted users have been removed." Could this be another remnant bug? |
|
Ok, gave 9.1.3 another try with an older (9.0.6) database backup and 4Gigs of RAM for the PHP process. It tooks 16 hours but works. Not sure but maybe my database was corrupted in 9.0.7. |
|
Trying to reproduce the one time working upgrade with no luck. (from 8.2.9 over) 9.0.7 to 9.1.3 with live DB is stuck again. |
|
9.0.6 to 9.1.3 is broken too. Here are the last two SQL queries before the |
|
After a bit longer search I've found a (workaround) solution: The problem obviously belongs to the CamelCase naming of the PHP code files in 9.1.x. If you rename the 'apps/federatedfilesharing/lib/DiscoveryManager.php' to 'discoverymanager.php' in lowercases like in 9.0.x the update will run thru without any errors. I was able to reproduce this behavior for multiple times. So it works now. But the question is: What's the reason for this? |
|
That might be an important clue you found. In 9.1 the autoloader logic was reworked to use properly camel cased classes which also brings a performance boost. All classes that could not be renamed were moved into a "legacy" subfolder were the old less-efficient autoloader. Maybe on your setup the old autoloader was still cached by PHP (APCu?) and it was trying to load the new classes with the old autoloader code. But some reporter said that clearing this cache did not help, so not sure. @DeepDiver1975 @VicDeo @jvillafanez any idea ? |
|
A caching problem would make sense. APCu is used but does this matter for the CLI mode? If that is the root of the problem the updater should clear all caches before starting to work I think... |
|
I'm not sure if it's able to. There was a very old discussion about issues with clearing the cache #18475 but I'm not sure they are relevant here. @VicDeo would it be possible to occ upgrade to clear the APCu cache, if that even makes sense ? One problem I see is that the code that clears the cache already needs to be loaded, so at least that specific code path needs to always work even with non-cleared cache. |
|
in the config i still had configured a different apps path that was pointing to |
|
adding xdebug in production ... yay |
|
|
|
I f you can reproduce, does adding a case-sensitive version of the classname to the list of searched paths in the autoloader help? i.e. after line 113 in lib/autoloader.php |
|
ok ... the federatedfilesharing app is not loaded when the MoveAvatarOutsideHome repair step is executed. diff --git a/lib/private/Repair/MoveAvatarOutsideHome.php b/lib/private/Repair/MoveAvatarOutsideHome.php
index 53e34a2..1a5436d 100644
--- a/lib/private/Repair/MoveAvatarOutsideHome.php
+++ b/lib/private/Repair/MoveAvatarOutsideHome.php
@@ -104,6 +104,7 @@ class MoveAvatarOutsideHome implements IRepairStep {
private function moveAvatars(IOutput $out, IUser $user) {
$userId = $user->getUID();
+ \OC_App::loadApp('federatedfilesharing');
\OC\Files\Filesystem::initMountPoints($userId);
// call get instead of getUserFolder to avoid needless skeleton copyThis is not the correct solution, bit it raises the question if we need to make federatedfilesharing apptype filesystem in info.xml. the dependency was introduced with #24073 (diff) and a possible dependency problem was deferred to a later PR ... which I assume never came for ... reasons. cc @DeepDiver1975 @PVince81 make federatedfilesharing apptype filesystem? |
|
this is the wrong code location - this can be triggered by any repair step. maybe the repair step command class needs to load all apps? for the bigger picture: it was wrong in the first place to use the discovery manager class in sharing |
|
this just proves that the exception is triggered by a dependency of files_sharing on federatedfilesharing. as I wrote above:
|
|
working on a PR |
|
needed to change quite a bit: #28004 |
|
Same problem here: upgrading from OC 9.1.6 to OC 10.0.2 on Debian 8 fails with "Fatal error: Class 'OCA\FederatedFileSharing\DiscoveryManager' not found" We found a workaround. If you disable maintenance mode before upgrade the process works smoothly and ends without errors. |
butonic
added
p2-high
|
We tested with a 20K users installation and like @ronbailer says: forcing the maintenance more to off and immediately adding the upgrade works. @tomneedham @butonic why? 😕 |
|
@cdamken Workaround: load Fix: Follow design guides and remove a direct cross-app dependency. This is what Joern and Tom are doing in #28004 |
|
@VicDeo Thanks |
felixboehm
added
p1-urgent
ghost
mentioned this issue
|
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
Get usable current version
Actual behaviour
Server configuration
Operating system: CentOS Linux release 7.2.1511
Web server: Apache/2.4.6 (CentOS)
Database: mysql Ver 15.1 Distrib 5.5.50-MariaDB, for Linux (x86_64) using readline 5.1
PHP version: PHP 7.0.11
ownCloud version (see ownCloud admin page): 9.0.3.2 -> 9.1.1.3
Updated from an older ownCloud or fresh install: upgrade
ownCloud log (data/owncloud.log, see https://central.owncloud.org/t/how-to-find-webserver-or-oc-logfile-enable-php-logfile/808): no information provided
Special configuration (external storage, external authentication, reverse proxy, server-side-encryption): LDAP
The text was updated successfully, but these errors were encountered: