Upgrading from OC6.04 to OC7 stops at "This ownCloud instance is currently being updated..."

[baldurmen]

Steps to reproduce

- upgrade from 6.0.4 to 7.0.0 following http://doc.owncloud.org/server/7.0/admin_manual/maintenance/update.html but with apt-get upgrade - server upgrade procedure launched by accessing the server using a browser connexion. - "Updating ownCloud to version 7.0.0, this may take a while." - The same + "Please reload the page" - "This ownCloud instance is currently being updated, which may take a while...."

Expected behaviour

login screen

Actual behaviour

screen with "Updating ownCloud to version 7.0.0, this may take a while..."

Server configuration

Operating system: Debian testing (jessie)

Web server: apache 2.4.10-1

Database: mysql 5.5.37

PHP version: php5 5.6.0RC2

ownCloud version: 7.0.0+dfsg-1 (debian testing)

Updated from an older ownCloud: 6.0.4+dfsg-1

List of activated apps: no 3party apps installed

The content of config/config.php:

'occ8905d32ce', 'passwordsalt' => 'XXX', 'trusted_domains' => array ( 0 => 'cloud.sogeecom.org', ), 'datadirectory' => '/data/Owncloud-data/data', 'dbtype' => 'mysql', 'version' => '6.0.4.1', 'appstoreenabled' => false, 'apps_paths' => array ( 0 => array ( 'path' => '/usr/share/owncloud/apps', 'url' => '/apps', 'writable' => false, ), ), 'dbname' => 'owncloud', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'owncloud', 'dbpassword' => 'XXX', 'installed' => true, 'ldapIgnoreNamingRules' => false, 'forcessl' => true, 'enable_previews' => false, 'theme' => '', 'maintenance' => true, ); **Are you using external storage, if yes which one:** yes, local **Are you using encryption:** no

Client configuration

**Browser:** firefox **Operating system:** debian

Logs

- Nothing in /var/log/owncloud.log - Nothing in /var/log/mysql/error.log - Nothing in /var/log/apache2/error.log

Comments

When the update starts, I can see mysql using cpu. A short while after reloading the page, mysql stops and everything returns to idle. version.php shows this:

[ghost]

I have the same issue only difference is upgrading from 7.0 RC1 to 7.0 Full Release. :(

[DeepDiver1975]

If you reload the page while the upgrade is in progress you will receive the maintenance page just like anybody else.

Change the config parameter 'maintenance_mode' to false in your config/config.php and reload - the upgrade process then can continue

[baldurmen]

I did this multiple times without success during the past few days. I get the same sequence as described in "steps to reproduce".

Not reloading the page does not change anything. This is the page I get before reloading.

[ghost]

I have tried the same and I still get the upgrade notice.

[baldurmen]

Hmm, I tried to copy /owncloud from my working OC7 server to the one posing problem (replacing config.php and the data folder) without success.

I don't know what else I can post the help, but I could post the full mysql log of the update process. I won't do it unless someone asks for it since it's quite long.

[silverhook]

I just stumbled upon the same error when updating from 6.0.4 to 7.0.1 on Gentoo via its webapp-config.

I’m running PHP 5.5 and PostgreSQL 9.3 if that’s relevant in any case.

The changing the maintenance mode did not help either.

[StephaneCouturier]

Hi, I face the same issue, using a mysql db,
When I change 'maintenance' => false, I also come back every time to the initial Start update page.

[raimund-schluessler]

I can confirm this issue too. Had this problem when upgrading from 6.0.4 to 7.0.0 (worked around it by a fresh install and importing all database entries necessary) and now again from 7.0.0 to 7.0.1. The setup is very similar to the one of @baldurmen, only standard apps enabled and external (local) storage linked.

@DeepDiver1975 The update page was not reloaded manually, but showed the image @baldurmen posted on its own after 30 s. Reloading the page then brings the maintenance page, setting 'maintenance_mode' to false afterwards results in an infinite update loop. (With infinite = 30min, I canceled trying then). No error logs are shown though.

Edit:
PHP version: PHP Version 5.5.15-1~dotdeb.1
MySQL: 5.5.38-0+wheezy1

[StephaneCouturier]

I may have found a clue: each time I ran the updater, new tables where created.
They look like temporary tables from the update process ( with twice the prefix, and random numbers at the end).
They seem not to have been deleted because the process did not go all the way.

oc_oc_appconfig_2f9826653b61e
oc_oc_appconfig_4f133d1e5a330
oc_oc_appconfig_26ae23cfd7d68
oc_oc_appconfig_c04624de53e16
oc_oc_appconfig_d73afee22ec20
oc_oc_appconfig_df29fb02bbca1
oc_oc_appconfig_e6f9a4329a159
oc_oc_appconfig_f04ea7bf19d56
oc_oc_jobs_4fdd1841b7ca0
oc_oc_jobs_71e4cd8cae43e
oc_oc_jobs_84c8aefe21a5a
oc_oc_jobs_188d5db5690fe
oc_oc_jobs_94534b8673fee
oc_oc_jobs_b70b1035a673d
oc_oc_jobs_cec2328de7b2e
oc_oc_preferences_07c88138f6172
oc_oc_privatedata_15b4b54e31232
oc_oc_privatedata_c91d4df5473a3
oc_oc_properties_0373feffa2567
oc_oc_properties_2fe7ebb907801
oc_oc_properties_7ba415df2ff07
oc_oc_properties_17e89220b989d
oc_oc_properties_2424fa1165620
oc_oc_properties_6106919835688
oc_oc_properties_a233d6de7d9bf
oc_oc_properties_b70f8e6bb3c58
oc_oc_properties_fc63beee14584
oc_oc_share_43a8403ef1cf1
oc_oc_share_a164366f925c5
oc_oc_users_091b0207cc690
oc_oc_users_90653c13966ed
oc_oc_users_7051473d12398
oc_oc_users_e8140eed798d5
oc_oc_users_ebe4770daa203
oc_oc_vcategory_4a630b2160a9a
oc_oc_vcategory_8b7a8e68ba00d
oc_oc_vcategory_caa90a8c1d9c2
oc_oc_vcategory_to_object_a51049a68b391

I dropped them and tried the update again, and it created 2 other ones like that again:

oc_oc_jobs_7d88a1a14fab5
oc_oc_privatedata_21c460c6bfe1c

and again

oc_oc_preferences_0c3b535a8e54c
oc_oc_properties_09108e135f101

and again

oc_oc_jobs_ef253ccbabd18
oc_oc_properties_26b6cb92bc625
oc_oc_share_37f4ae9d022a8

[raimund-schluessler]

I can confirm this. Lots of these tables are created.

[StephaneCouturier]

Also, while doing some of these updates, I used phpmyadmin to view the tables appearing and disappearing during the update.
But on one occasion I got the following error from the oc updater:
An exception occurred while executing 'SELECT DISTINCT(TABLE_NAME) AStableFROM INFORMATION_SCHEMA . COLUMNS WHERE TABLE_SCHEMA = ? AND (COLLATION_NAME <> 'utf8_bin' OR CHARACTER_SET_NAME <> 'utf8') AND TABLE_NAME LIKE "oc_%"' with params ["name_of_my_db"]: SQLSTATE[70100]: <>: 1317 Query execution was interrupted

[silverhook]

As for postgresql, I can confirm that it was running for quite a while, but I didn’t bother checking what it was doing exactly.

[PVince81]

The temporary tables are created to simulate an update of the data to the new schema. They should be deleted automatically if the upgrade process completes. Not sure why it hangs in your case.

Did you guys find any errors in the log from the time the upgrade was running ?
Do you all have empty logs, even when setting loglevel to 0 ?

Have you tried the command line update ./occ upgrade instead of the web UI ?
This could help rule out possible timeout issues in case the upgrade takes too long.

[baldurmen]

@PVince81 I'll look at this as soon as possible. Thanks for input.

[baldurmen]

HA! I upgraded via the cli interface (this should deffinitly be referenced in the doc) and here is the log I get:

An unhandled exception has been thrown:
exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP 'PRIMARY'; check that column/key exists' in /usr/share/php/Doctrine/DBAL/Connection.php:801
Stack trace:
#0 /usr/share/php/Doctrine/DBAL/Connection.php(801): PDO->query('ALTER TABLE oc...') #1 /usr/share/owncloud/lib/private/db/migrator.php(181): Doctrine\DBAL\Connection->query('ALTER TABLEoc...')
#2 /usr/share/owncloud/lib/private/db/migrator.php(35): OC\DB\Migrator->applySchema(Object(Doctrine\DBAL\Schema\Schema))
#3 /usr/share/owncloud/lib/private/db/mdb2schemamanager.php(99): OC\DB\Migrator->migrate(Object(Doctrine\DBAL\Schema\Schema))
#4 /usr/share/owncloud/lib/private/db.php(320): OC\DB\MDB2SchemaManager->updateDbFromStructure('/usr/share/ownc...')
#5 /usr/share/owncloud/lib/private/app.php(1172): OC_DB::updateDbFromStructure('/usr/share/ownc...')
#6 /usr/share/owncloud/lib/private/app.php(980): OC_App::updateApp('user_ldap')
#7 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('user_ldap')
#8 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('user_ldap')
#9 /usr/share/owncloud/apps/files_sharing/appinfo/update.php(67): OC_App::loadApps(Array)
#10 /usr/share/owncloud/apps/files_sharing/appinfo/update.php(10): removeSharedFolder()
#11 /usr/share/owncloud/lib/private/app.php(1179): include('/usr/share/ownc...')
#12 /usr/share/owncloud/lib/private/app.php(980): OC_App::updateApp('files_sharing')
#13 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('files_sharing')
#14 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('files_sharing')
#15 /usr/share/owncloud/console.php(26): OC_App::loadApps()
#16 /usr/share/owncloud/occ(11): require_once('/usr/share/ownc...')
#17 {main}

Next exception 'Doctrine\DBAL\DBALException' with message 'An exception occurred while executing 'ALTER TABLE oc_ldap_user_mapping DROP PRIMARY KEY':

SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP 'PRIMARY'; check that column/key exists' in /usr/share/php/Doctrine/DBAL/DBALException.php:91
Stack trace:
#0 /usr/share/php/Doctrine/DBAL/Connection.php(811): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException), 'ALTER TABLE oc...') #1 /usr/share/owncloud/lib/private/db/migrator.php(181): Doctrine\DBAL\Connection->query('ALTER TABLEoc...')
#2 /usr/share/owncloud/lib/private/db/migrator.php(35): OC\DB\Migrator->applySchema(Object(Doctrine\DBAL\Schema\Schema))
#3 /usr/share/owncloud/lib/private/db/mdb2schemamanager.php(99): OC\DB\Migrator->migrate(Object(Doctrine\DBAL\Schema\Schema))
#4 /usr/share/owncloud/lib/private/db.php(320): OC\DB\MDB2SchemaManager->updateDbFromStructure('/usr/share/ownc...')
#5 /usr/share/owncloud/lib/private/app.php(1172): OC_DB::updateDbFromStructure('/usr/share/ownc...')
#6 /usr/share/owncloud/lib/private/app.php(980): OC_App::updateApp('user_ldap')
#7 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('user_ldap')
#8 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('user_ldap')
#9 /usr/share/owncloud/apps/files_sharing/appinfo/update.php(67): OC_App::loadApps(Array)
#10 /usr/share/owncloud/apps/files_sharing/appinfo/update.php(10): removeSharedFolder()
#11 /usr/share/owncloud/lib/private/app.php(1179): include('/usr/share/ownc...')
#12 /usr/share/owncloud/lib/private/app.php(980): OC_App::updateApp('files_sharing')
#13 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('files_sharing')
#14 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('files_sharing')
#15 /usr/share/owncloud/console.php(26): OC_App::loadApps()
#16 /usr/share/owncloud/occ(11): require_once('/usr/share/ownc...')
#17 {main}

Next exception 'RuntimeException' with message 'Failed to upgrade "user_ldap".' in /usr/share/owncloud/lib/private/app.php:985
Stack trace:
#0 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('user_ldap')
#1 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('user_ldap')
#2 /usr/share/owncloud/apps/files_sharing/appinfo/update.php(67): OC_App::loadApps(Array)
#3 /usr/share/owncloud/apps/files_sharing/appinfo/update.php(10): removeSharedFolder()
#4 /usr/share/owncloud/lib/private/app.php(1179): include('/usr/share/ownc...')
#5 /usr/share/owncloud/lib/private/app.php(980): OC_App::updateApp('files_sharing')
#6 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('files_sharing')
#7 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('files_sharing')
#8 /usr/share/owncloud/console.php(26): OC_App::loadApps()
#9 /usr/share/owncloud/occ(11): require_once('/usr/share/ownc...')
#10 {main}

Next exception 'RuntimeException' with message 'Failed to upgrade "files_sharing".' in /usr/share/owncloud/lib/private/app.php:985
Stack trace:
#0 /usr/share/owncloud/lib/private/app.php(87): OC_App::checkUpgrade('files_sharing')
#1 /usr/share/owncloud/lib/private/app.php(72): OC_App::loadApp('files_sharing')
#2 /usr/share/owncloud/console.php(26): OC_App::loadApps()
#3 /usr/share/owncloud/occ(11): require_once('/usr/share/ownc...')

This error message is show whatever the option I'm using with ./occ (even options thatr do not exist).

[raimund-schluessler]

For me it seems to be a timeout issue. Using php occ upgrade the update runs without errors in the log. Thanks for the hint!

[silverhook]

Here’s my php ./occ upgrade output, of which the result is again the “upgrade” screen in the browser:

An unhandled exception has been thrown:
exception 'PDOException' with message 'SQLSTATE[42P07]: Duplicate table: 7 ERROR:  relation "id" already exists' in /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:742
Stack trace:
#0 [internal function]: PDO->query('CREATE UNIQUE I...')
#1 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(742): call_user_func_array(Array, Array)
#2 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db/migrator.php(181): Doctrine\DBAL\Connection->query('CREATE UNIQUE I...')
#3 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db/migrator.php(35): OC\DB\Migrator->applySchema(Object(Doctrine\DBAL\Schema\Schema))
#4 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db/mdb2schemamanager.php(99): OC\DB\Migrator->migrate(Object(Doctrine\DBAL\Schema\Schema))
#5 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db.php(320): OC\DB\MDB2SchemaManager->updateDbFromStructure('/var/www/thatfu...')
#6 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(1172): OC_DB::updateDbFromStructure('/var/www/thatfu...')
#7 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(980): OC_App::updateApp('bookmarks')
#8 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(87): OC_App::checkUpgrade('bookmarks')
#9 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(72): OC_App::loadApp('bookmarks')
#10 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/console.php(26): OC_App::loadApps()
#11 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/occ(11): require_once('/var/www/thatfu...')
#12 {main}

Next exception 'Doctrine\DBAL\DBALException' with message 'An exception occurred while executing 'CREATE UNIQUE INDEX id ON oc_bookmarks ("id")':

SQLSTATE[42P07]: Duplicate table: 7 ERROR:  relation "id" already exists' in /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:47
Stack trace:
#0 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(744): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(PDOException), 'CREATE UNIQUE I...')
#1 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db/migrator.php(181): Doctrine\DBAL\Connection->query('CREATE UNIQUE I...')
#2 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db/migrator.php(35): OC\DB\Migrator->applySchema(Object(Doctrine\DBAL\Schema\Schema))
#3 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db/mdb2schemamanager.php(99): OC\DB\Migrator->migrate(Object(Doctrine\DBAL\Schema\Schema))
#4 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/db.php(320): OC\DB\MDB2SchemaManager->updateDbFromStructure('/var/www/thatfu...')
#5 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(1172): OC_DB::updateDbFromStructure('/var/www/thatfu...')
#6 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(980): OC_App::updateApp('bookmarks')
#7 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(87): OC_App::checkUpgrade('bookmarks')
#8 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(72): OC_App::loadApp('bookmarks')
#9 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/console.php(26): OC_App::loadApps()
#10 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/occ(11): require_once('/var/www/thatfu...')
#11 {main}

Next exception 'RuntimeException' with message 'Failed to upgrade "bookmarks".' in /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php:985
Stack trace:
#0 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(87): OC_App::checkUpgrade('bookmarks')
#1 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/lib/private/app.php(72): OC_App::loadApp('bookmarks')
#2 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/console.php(26): OC_App::loadApps()
#3 /var/www/thatfunkyplace.wheremymonkeyis.at/htdocs/occ(11): require_once('/var/www/thatfu...')
#4 {main}#                                                                                    

[PVince81]

@baldurmen strange. Did you upgrade to 7.0.0 or 7.0.1 ?
CC @blizzz for LDAP error.

@silverhook your issue seem to be related to the bookmarks apps. You can try disabling it before upgrading and enable it afterwards. It might not solve the issue though. You might want to report it in the https://github.com/owncloud/bookmarks repo with more details about your setup.

[silverhook]

@PVince81 , reported, thanks. Since it seems to be a proper bug, I’ll just wait for the fix.

[blizzz]

this drop primary key.... could be a duplicate of #9893

[baldurmen]

@PVince81 While waiting for an answer, the debian testing reposirories updated to 7.0.1. Sorry if it messes up things.

[baldurmen]

Weell, since productive work starts soon where I work, I simply reinstalled Owncloud, reconfigured it and transfered the data. I can't be much further help for debugging.

[fotastisch]

I have the same problem?
Any solutions yet?

Thanks!

[fotastisch]

Oh, I had not seen the part with php occ upgrade...

Worked for me!

[StephaneCouturier]

"Weell, since productive work starts soon where I work, I simply reinstalled ownCloud, reconfigured it and transfered the data. I can't be much further help for debugging."

Hi, I had to do the same, I cannot use the occ upgrade as I am using a shared web host without access to command line.

I just tried updating from 7.0.1 to 7.0.2 and I have again the same problem.

[PVince81]

Hmmm... the problem with shared hosters is that they possibly have a short PHP timeout and also do not always allow command line updating. The problem with the short PHP timeout is that if the upgrade takes longer, it might break it in the middle, for which the "solution" is to run the CLI upgrade, which is not available for some shared hosters 😦

@StephaneCouturier do you have lots of shared files and can confirm that the upgrade takes a long time in your case ?

Reopening this to discuss possible solutions for shared hosters where CLI upgrade is not possible.

[PVince81]

@StephaneCouturier you might be able to manually disable maintenance mode and resume the upgrade.

[StephaneCouturier]

@PVince81, thanks for the support and keeping the topic opened.
Disabling the maintenance mode does not solve the problem unfortunately.
I have 650 files, 1Gb approx, the upgrade takes around 4-5 minutes before a message asking to reload is displayed.

Many French users of ownCloud and of the same shared web most are collaborating on this page: http://open-freax.fr/owncloud-7-mutu-ovh/ and I only see one report of the issue which was fixed by switching back the maintenance mode. So I still wonder if the issue is linked to the host, to the files, or to the db (I had installed 7.0.1 from scratch, importing vcards and calendars saved previously).

I have a second web site with the same host. I will install a 7.0.1 from scratch and try and update to 7.0.2 to see if I can reproduce the same issue.
I'll keep you posted.

[StephaneCouturier]

Hi,

I made some more tests, but I still haven't solved the issue.

Using a different website with the same shared web host, I could upgrade without issue from 7.0.1 to 7.0.2. (the database had only imported contacts, imported calendars, and the few oC default documents).
The operation took less than 1min. I noticed the browser reloading early during the procedure. And after about 30s, I got the message that the update was successful.

On the first website, I did the following test: I moved all data to a temporary folder to see if this is what is causing the timeout/issue. The update failed again nonetheless. I noticed the browser did no seem to be loading something as it did is the successful update of the second site.

So the issue does seem to be linked with shared web host.
Here is what I'll try next to find a more local cause:

• backup the mysql db / export contacts & calendars / back up files
• remove oc tables and install 7.0.1 from scratch.
• try the update to 7.0.2
• if successful, try the same sequence with some (maybe not all 650) files present before the update

[enoch85]

I’m closing this issue because it has been inactive for a few months. This probably means that the issue is not reproducible or it has been fixed in a newer version.

Please reopen if you still encounter this issue with the latest stable version and then please use the issue template. You can also contribute directly by providing a patch – see the developer manual. :)

Thank you!

[StephaneCouturier]

Hi, FYI I never solved the issue with oc 7.xx but it got fixed with oc 8.
The upgrade to oc 8 went very smoothly.
Thanks a lot for the great work!