Upgrade stuck on "Updating database schema"

Steps to reproduce

  1. run “occ update”

Expected behaviour

I am updating from 10.0.x to the latest 10. When starting up the update I had to disable a few apps, otherwise all seems fine. Anyhow, the process seems to get stuck in “Updating database schema”. I have been waiting for it for a few hours now but it seems not to continue. Is this normal / expected behaviour?

Checking out the processes, there a few MySQL processes going on. The database is on the local disk of the virtual Ubuntu 16. There is something around 10% of processor capacity in use. The database size is 19G.

Server configuration

Virtual Ubuntu 16.04 on Xeon X5570 host, using common KVM mode (Proxmox latest as host environment)

Web server:
Apache
Database:
MySQL
PHP version:
PHP 7
ownCloud version: (see ownCloud admin page)
10,1,0,4
Updated from an older ownCloud or fresh install:
trying to update, originally installed as version 10

The content of config/config.php:

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
{
“system”: {
“updatechecker”: false,
“instanceid”: “oc0pvjv9mo9f”,
“passwordsalt”: “REMOVED SENSITIVE VALUE”,
“secret”: “REMOVED SENSITIVE VALUE”,
“trusted_domains”: [
media.toastpost.com”,
“10.10.10.68”,
“10.10.10.68”,
“10.10.10.66”
],
“datadirectory”: “/var/owncloud-data”,
“overwrite.cli.url”: “https://media.toastpost.com/cloud”,
“dbtype”: “mysql”,
“version”: “10.0.2.1”,
“dbname”: “ocdatabase”,
“dbhost”: “localhost”,
“dbtableprefix”: “oc_”,
“dbuser”: “REMOVED SENSITIVE VALUE”,
“dbpassword”: “REMOVED SENSITIVE VALUE”,
“logtimezone”: “UTC”,
“installed”: true,
“theme”: “”,
“loglevel”: 0,
“log_rotate_size”: 100100100,
“log_rotate_sizerotation”: 1100100100,
“maintenance”: true,
“mail_from_address”: “REMOVED SENSITIVE VALUE”,
“mail_smtpmode”: “smtp”,
“mail_domain”: “REMOVED SENSITIVE VALUE”,
“mail_smtphost”: “REMOVED SENSITIVE VALUE”,
“mail_smtpport”: “25”,
“ldapIgnoreNamingRules”: false,
“files_external_allow_create_new_local”: true,
“debug”: false,
“onlyoffice”: {
“verify_peer_off”: true
},
“memcache.local”: “\OC\Memcache\APCu”,
“memcache.locking”: “\OC\Memcache\APCu”
}
}

List of activated apps:

Enabled:

  • calendar: 1.6.2
  • comments: 0.3.0
  • configreport: 0.1.1
  • dav: 0.2.9
  • diagnostics: 0.1.4
  • drawio: 0.0.8
  • federatedfilesharing: 0.3.0
  • federation: 0.1.0
  • files: 1.5.1
  • files_external: 0.7.0
  • files_sharing: 0.10.0
  • files_trashbin: 0.9.0
  • files_versions: 1.3.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • market: 0.4.0
  • notifications: 0.3.0
  • onlyoffice: 2.3.1
  • provisioning_api: 0.5.0
  • systemtags: 0.3.0
  • updatenotification: 0.2.1
  • user_external: 0.4
    Disabled:
  • encryption
  • external
  • theme-example

Are you using external storage, if yes which one: local/smb/sftp/…
YES
Are you using encryption: yes/no
NO
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…
NO

Hello,

the occ upgrade can be quite long, if you have a 19GB database I’m not surprised it takes a while, sometimes you have an ALTER TABLE which does some copy. I’d recommend you to do it again and keep an eye on your MySQL’s processlist. You just open the MySQL shell and type SHOW PROCESSLIST; or SHOW FULL PROCESSLIST;. Turn the maintenance on and turn off the cron so you won’t touch the database while the upgrading process runs.

1 Like

If you want to keep a constant eye on your processlist you could run the command like so:

watch -n 1 mysqladmin processlist
2 Likes