Closed pejakm closed 8 years ago
I used sqlitebrowser to remove oc_addressbooks
table as well as other conflicting tables, and triggered upgrade again, this is what happened after a while:
https://lut.im/43NKVSrD5S/71Avk8bzE9RDr9PH.png
Looking at data
folder, the file owncloud.db-wal
continued to grow to some 30 MB (the database file itself is 4,5 MB).
It appears that upgrade process timed out:
PHP message: PHP Warning: flock() expects parameter 1 to be resource, boolean given in /usr/share/webapps/owncloud/lib/private/config.php on line 197
PHP message: PHP Fatal error: Uncaught Error: Call to a member function getRequest() on null in /usr/share/webapps/owncloud/lib/private/response.php:77
Stack trace:
#0 /usr/share/webapps/owncloud/status.php(51): OC_Response::setStatus(500)
#1 {main}
thrown in /usr/share/webapps/owncloud/lib/private/response.php on line 77" while reading response header from upstream, client: 192.168.1.3, server: daimonion.eu.org, request: "GET /owncloud/status.php HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/php-fpm.sock:", host: "daimonion.eu.org"
2016/03/08 18:15:36 [error] 11882#0: *42 upstream timed out (110: Connection timed out) while reading upstream, client: 192.168.1.3, server: daimonion.eu.org, request: "GET /owncloud/core/ajax/update.php?requesttoken=EHMxIgM5IzsxJCxKCVQfCCE0LRsqHBAvAjBfegcWd3M%3D%3AiJCKIaIIVtz298hLLSFsCEDBdE9%2BjQ1C6vpMj1QDNOs%3D HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/php-fpm.sock:", host: "daimonion.eu.org"
first i started upgrade process, but it hanged, I had to refresh the page
Can you define "hanged"? At which step was that?
Perhaps it was related to low script execution time. I have no idea what and how it happened, but after some time I can log in again to my ownCloud. It appears the upgrade succeeded after all. However, I'm facing a lot of other problems right now (with calendar, contacts and tasks modules), so for now I will revert to 8.2.2.
@pejakm For timeout issues its always the best to run the upgrade from command line via occ.
Its also really advised that you switch from SQLite to MySQL/PostgreSQL for the reason described in the documentation.
I tried once again, and the same happened: this error, but I could see owncloud.db-wal
file getting bigger, and sometime when it reached ~32MB it disappeared. After that I could log into my upgraded ownCloud.
Between two upgrade attempts you have to reset your DB to the 8.2.2 version. That means delete all tables and then restore the backup.
I just wanted to report that I got this same exact error with ownCloud on my Raspberry Pi 2 Model B. Here's the error if this will help at all:
Doctrine\DBAL\Exception\TableExistsException: An exception occurred while executing 'CREATE TABLE "oc_addressbooks" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "principaluri" VARCHAR(255) DEFAULT NULL, "displayname" VARCHAR(255) DEFAULT NULL, "uri" VARCHAR(255) DEFAULT NULL, "description" VARCHAR(255) DEFAULT NULL, "synctoken" INTEGER UNSIGNED DEFAULT 1 NOT NULL)': SQLSTATE[HY000]: General error: 1 table "oc_addressbooks" already exists
Between two upgrade attempts you have to reset your DB to the 8.2.2 version. That means delete all tables and then restore the backup.
Closing as such. If you update page hangs, you can not simply refresh, you need to reset atm.
Also when you are on a raspberrypi, you should have access to the console.
In which case ./occ upgrade
is the recommended way to update, to avoid timeouts.
Happened here as well, trying to upgrade from 8.2.2-1.1 to 9.0.0-1.1 (Debian/Jessie packages):
$ sudo -u www-data php ./occ upgrade ownCloud or one of the apps require upgrade - only a limited number of commands are available You may use your browser or the occ upgrade command to do the upgrade Set log level to debug Checking whether the database schema can be updated (this can take a long time depending on the database size) Checked database schema update Checking updates of apps Checking whether the database schema forcan be updated (this can take a long time depending on the database size) Checking whether the database schema for can be updated (this can take a long time depending on the database size) Checking whether the database schema for can be updated (this can take a long time depending on the database size) Checked database schema update for apps Updating database schema Updated database Disabled 3rd-party app: bookmarks Disabled incompatible app: calendar Disabled 3rd-party app: calendar Disabled incompatible app: contacts Disabled 3rd-party app: contacts Disabled 3rd-party app: files_videoviewer Disabled 3rd-party app: updater Updating ... Updated to 0.8 Updating ... Updated to 2.1 Updating ... Updated to 14.5.0 Updating ... Updated to 1.4.4 Updating ... Updated to 2.2.1 Updating ... Updated to 0.9.1 Updating ... Updated to 0.8.0 Updating ... Updated to 1.2.0 Update 3rd-party app: calendar Update 3rd-party app: contacts Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occurred while executing 'PRAGMA journal_mode = WAL': SQLSTATE[HY000]: General error: 10 disk I/O error Update failed Maintenance mode is kept active Reset log level PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 10 disk I/O error' in /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:77 Stack trace: #0 /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(77): PDO->prepare('UPDATE "oc_file...', Array) #1 /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(984): Doctrine\DBAL\Driver\PDOConnection->prepare('UPDATE "oc_file...') #2 /var/www/owncloud/lib/private/db/connection.php(205): Doctrine\DBAL\Connection->executeUpdate('UPDATE "oc_file...', Array, Array) #3 /var/www/owncloud/lib/private/lock/dblockingprovider.php(263): OC\DB\Connection->executeUpdate('UPDATE `*PREFIX...', Array) #4 [internal function]: OC\Lock\DBLockingProvider->releaseAll() #5 {main} Next exception 'Doctrine\DBAL\Driver\PDOException' with message 'SQLSTATE[HY000]: General error: 10 disk I/O error' in /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:7 in /var/www/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractSQLiteDriver.php on line 85
The occ
command did not "hang" but returned rather quickly. Successive runs of the same command come back in under a second with the "oc_addressbooks already exists" error:
ownCloud or one of the apps require upgrade - only a limited number of commands are available You may use your browser or the occ upgrade command to do the upgrade Set log level to debug Checking whether the database schema can be updated (this can take a long time depending on the database size) Checked database schema update Checking updates of apps Checked database schema update for apps Updating database schema Updated database Doctrine\DBAL\Exception\TableExistsException: An exception occurred while executing 'CREATE TABLE "oc_addressbooks" ("id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "principaluri" VARCHAR(255) DEFAULT NULL, "displayname" VARCHAR(255) DEFAULT NULL, "uri" VARCHAR(255) DEFAULT NULL, "description" VARCHAR(255) DEFAULT NULL, "synctoken" INTEGER UNSIGNED DEFAULT 1 NOT NULL)': SQLSTATE[HY000]: General error: 1 table "oc_addressbooks" already exists Update failed Maintenance mode is kept active Reset log level
For whatever reason, the oc_addressbooks
was empty, even though the Contacts application is used. After dropping it, occ upgrade
progressed but hit the same error for other tables:
SQLSTATE[HY000]: General error: 1 table "oc_addressbooks" already exists SQLSTATE[HY000]: General error: 1 table "oc_cards" already exists SQLSTATE[HY000]: General error: 1 table "oc_addressbookchanges" already exists SQLSTATE[HY000]: General error: 1 table "oc_calendarobjects" already exists SQLSTATE[HY000]: General error: 1 table "oc_calendars" already exists SQLSTATE[HY000]: General error: 1 table "oc_calendarchanges" already exists SQLSTATE[HY000]: General error: 1 table "oc_calendarsubscriptions" already exists SQLSTATE[HY000]: General error: 1 table "oc_schedulingobjects" already exists SQLSTATE[HY000]: General error: 1 table "oc_cards_properties" already exists SQLSTATE[HY000]: General error: 1 table "oc_dav_shares" already exists
Every table was empty (maybe the upgrade process stored its data in a backup table?) and dropping each table made occ upgrade
finally complete, with all the data restored to the respective tables.
The only other riddle to solve after the upgrade to OC 9 is:
$ curl -sI https://www.example.org/owncloud/ | grep HTTP HTTP/1.1 404 Not Found $ curl -sI https://www.example.org/owncloud/index.php | grep HTTP HTTP/1.1 200 OK
But that's material for another report :)
We use MySQL as OC's backend database and I got the same error as those that use SQLite.
[root@owncloud html]# sudo -u apache php occ upgrade
ownCloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Set log level to debug
Checking whether the database schema can be updated (this can take a long time depending on the database size)
Checked database schema update
Checking updates of apps
Checked database schema update for apps
Updating database schema
Updated database
Doctrine\DBAL\Exception\TableExistsException: An exception occurred while executing 'CREATE TABLE oc_addressbooks
(id
BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, principaluri
VARCHAR(255) DEFAULT NULL, displayname
VARCHAR(255) DEFAULT NULL, uri
VARCHAR(255) DEFAULT NULL, description
VARCHAR(255) DEFAULT NULL, synctoken
INT UNSIGNED DEFAULT 1 NOT NULL, UNIQUE INDEX addressbook_index (principaluri
, uri
), PRIMARY KEY(id
)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = InnoDB':
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'oc_addressbooks' already exists Update failed Maintenance mode is kept active Reset log level
I forgot to ask in my last post: Is there a fix on this, or is the fix to drop all affected database tables?
The fix is to delete all tables, before restoring a backup when you want to retry the update.
And will this be fixed in a future version?
I got this as well, migrating from 8.2.3 to the current 9.0 version on linux mint 17.3 (same General error: 10 disk I/O error) I used the occ upgrade command.
I tried dumping all the tables as a fix, but it didn't work.
For my part, as I've backed up my owncloud folder, I've just gone back to the 8.2.3 version... (I like also using the sqlite backend for this reason, it's easy to go back to a previous database)
I'm facing the very same issue on the latest 9.1.3 version. Any suggestions how can I resolve 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.
Steps to reproduce
Expected behaviour
Upgrade should pass
Actual behaviour
Upgrade fails
Server configuration
Operating system: Arch Linux
Web server: nginx
Database: sqlite3
PHP version: 7.0.4
ownCloud version: 9.0.0
Updated from an older ownCloud or fresh install: upgrade from 8.2.2
Where did you install ownCloud from: Arch Linux official packages
Signing status (ownCloud 9.0 and above):
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Logs
Web server error log
ownCloud log (data/owncloud.log)