Horde DB conversion to SQLite failed - 11.50 update...
I've noticed on a few of our servers we are seeing this conversion process fail. Checking the log reveals that in most cases all users were converted except one problem account as follows...
It then proceeds to complete for all other accounts. At the end is a summary...
Error says to either raise a support request with cpanel or to re-run the process, but my guess is that all successful accounts will then be duplicated if I re-run it. I've got this problem on about a half dozen servers. I'd like to resolve it here, so that others with the same issue can also fix it (and I don't want to raise half a dozen individual support requests). Does the error "Horde database conversion to SQLite failed (action required)" mean that this whole process failed? Or if it will only affect this one user - can I re-run the process only for that user?
[2015-06-23 10:40:44 +0100] warn [horde_mysqltosqlite] [uid=538] 1[2015-06-23 10:40:44 +0100] warn [horde_mysqltosqlite] Moving the data for REDACTED appears to have failed
(child exited nonzero): The subprocess reported error 1 when it ended. at /usr/local/cpanel/Cpanel/Logger/Persistent.pm line 37
Cpanel::Logger::warn(Cpanel::Logger::persistent=HASH(0xb3a948), 'Moving the data for REDACTED appears to have failed (child exited nonzero):
The subprocess reported error 1 when it ended.') called at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 332
Cpanel::Horde::MySQLToSQLite::_convert_user(Cpanel::Horde::MySQLToSQLite=HASH(0x101c7f0), 'REDACTED') called at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 98
eval {...} called at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 98
Cpanel::Horde::MySQLToSQLite::convert_user(Cpanel::Horde::MySQLToSQLite=HASH(0x101c7f0), 'REDACTED') called at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 73
eval {...} called at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 73
Cpanel::Horde::MySQLToSQLite::convert_all_users(Cpanel::Horde::MySQLToSQLite=HASH(0x101c7f0)) called at /usr/local/cpanel/scripts/horde_mysqltosqlite line 39
main::try {...} () called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/Try/Tiny.pm line 81
eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/Try/Tiny.pm line 72
Try::Tiny::try(CODE(0xb3a8e8), Try::Tiny::Catch=REF(0xcba1d0)) called at /usr/local/cpanel/scripts/horde_mysqltosqlite line 51
main::run() called at /usr/local/cpanel/scripts/horde_mysqltosqlite line 19
It then proceeds to complete for all other accounts. At the end is a summary...
141/142 accounts successfully processed
[2015-06-23 10:44:23 +0100] warn [horde_mysqltosqlite] The conversion of Horde MySQL data to SQLite failed: The following accounts needed to be moved but could not due to
errors: REDACTED at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 86.
at /usr/local/cpanel/Cpanel/Logger/Persistent.pm line 37
Cpanel::Logger::warn(Cpanel::Logger::persistent=HASH(0xb3a948), 'The conversion of Horde MySQL data to SQLite failed:
The following accounts needed to be moved but could not due to errors: REDACTED at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 86.\x0A') called at
/usr/local/cpanel/scripts/horde_mysqltosqlite line 49 main::catch {...} ('The following accounts needed to be moved but could not due to errors:
REDACTED at /usr/local/cpanel/Cpanel/Horde/MySQLToSQLite.pm line 86.\x0A') called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/Try/Tiny.pm line 104
Try::Tiny::try(CODE(0xb3a8e8), Try::Tiny::Catch=REF(0xcba1d0)) called at /usr/local/cpanel/scripts/horde_mysqltosqlite line 51
main::run() called at /usr/local/cpanel/scripts/horde_mysqltosqlite line 19
Error says to either raise a support request with cpanel or to re-run the process, but my guess is that all successful accounts will then be duplicated if I re-run it. I've got this problem on about a half dozen servers. I'd like to resolve it here, so that others with the same issue can also fix it (and I don't want to raise half a dozen individual support requests). Does the error "Horde database conversion to SQLite failed (action required)" mean that this whole process failed? Or if it will only affect this one user - can I re-run the process only for that user?
-
Can you modify the script to allow it to be run with options? i.e --user ? I can check the existing Horde DB and see if the user has any data - if not, and assuming the SQLite DB wasn't created for that user, I could always simply run this... /usr/local/cpanel/bin/update_horde_config --user=bob 0 -
+1 for being able to run this for a specific user. Note, is /usr/local/cpanel/bin/update_horde_config the same thing as /usr/local/cpanel/scripts/horde_mysqltosqlite ? Being able to get more information about the incident might also be helpful. The logs for these incidents aren't much help: "Something went wrong converting the horde database for user %USER% to sqlite." And that appears to be the end of it. No real solution. The suggested solutions: 1) Open a support ticket - might be kind of burdensome if you suddenly get this error for a lot of servers and how long does it take cPanel to fix the issue? 2) Rerun the /usr/local/cpanel/scripts/horde_mysqltosqlite script - But this will recreate and duplicate (?) Horde entries for all of the users that were previously fixed. You also need to fix the issue that first caused this problem... which we're not going to tell you what that issue was, so good luck fixing it! 3) Do Nothing. Basically the default solution, even if it's not recommended because... there's not really a better solution. *shrugs* 0 -
I came across - blog.triantech.com/cpanel-upgrade-to-11-50-x-issues-with-horde-database - which said to run: /usr/local/cpanel/3rdparty/bin/perl -MCpanel::Horde::MySQLToSQLite -e 'Cpanel::Horde::MySQLToSQLite->new->convert_user("%CPANELUSERNAME%")'
I ran this for my affected user and it seemed to resolve the issue. Not sure why it failed when the cPanel 11.50 upgrade happened, but it went through when I manually ran this. I did verify that before /home/%CPANELUSERNAME%/.cphorde/horde.sqlite had tables, but no data. After running this above command - /home/%CPANELUSERNAME%/.cphorde/horde.sqlite - was populated with tables and data.0 -
Why this error message applies to DNS only cPanel installation also? It there any way to disable it? 0 -
Hello :) A few servers run in same problem can we solve it ourself by fixing a few users manual?
The "--user=" flag is available per the "help" output from /usr/local/cpanel/bin/update_horde_config:# /usr/local/cpanel/bin/update_horde_config --help Usage: /usr/local/cpanel/bin/update_horde_config [--user=...] This script is responsible for: 1. Creating the per-user SQLite databases for horde. 2. Keeping the Horde tables up to date with schema changes. 3. Assuring critical horde config variables are set correctly. It should be run: - After updating any Horde components that resulted in a change of db schema (with --full) - After creating a new cPanel account (with --user=) - Routinely (with no arguments) in order to make sure all users have a Horde SQLite database. - If the Horde database(s) ever need to be repaired after having tables dropped/lost (with --full) These uses of update_horde_config happen automatically, and administrators should only need to run it manually if they believe something has gone wrong with the automated run or with a Horde database. Arguments: --user=... Allows you to specify that you only want the per-user database operations to be performed for a single user, not for all users. The global operations (updating conf) will still be performed regardless of whether this option is specified or not. --full Check and upgrade the table schema instead of just checking that the per-user databases exist on disk. This schema check used to be done on every run of update_horde_config, but now that each user has their own copy of the Horde database, this was too time-consuming. The expectation now is that any updates to Horde that require schema upgrades (which are exceedingly rare so far) will include a one-time task to run update_horde_config --full. See also --deep. --deep Only affects the --full flag. When provided, the database check will perform a more thorough schema check. This check is much slower than the default, so it should mainly be used for debugging. --progress Report progress as each user is processed (noisy). --dbonly Only attempt to check / fix database problems; don't update the Horde system-wide configuration file. --confonly Only attempt to check / fix configuration problems; don't perform any Horde database schema checks. --dbversion=11.XX Create the database using Horde table schemas that were current as of cPanel & WHM version 11.XX. This is used by the backup restore system to facilitate restoring pre-11.50 Horde data. --create-defaults When creating or checking the database, ensure that the default address book and calendar are created. This option is suitable for manual use in the case where you are deleting and re-creating an entire database and want the default calendars and address books back. --delete-database Delete the destination database before doing anything else. This means that you will be creating an empty database to replace the original one. THIS WILL CAUSE PERMANENT DATA LOSS if you don't have a backup of the original database. --quiet Keep output to a minimum. Errors or warnings that are produced during the process may still slip through, but the normal output explaining what's being done will be suppressed. --confonly Only update the Horde system-wide configuration file and validate hooks.php files; don't attempt to check / fix database problems. Examples: Please see http://go.cpanel.net/hordetroubleshoot for example usage.
Can you modify the script to allow it to be run with options? i.e --user ?
Yes, the available options are listed above.Why this error message applies to DNS only cPanel installation also? It there any way to disable it?
Internal case CPANEL-445 is open to address an issue where DNS-Only servers with Horde databases are getting conversion errors. There's currently no time frame available on a release, but you can monitor our change logs at:0
Please sign in to leave a comment.
Comments
7 comments