Bug 409853 - akonadiserver runs dbinitializer even when db is already filled with data and dies
Summary: akonadiserver runs dbinitializer even when db is already filled with data and...
Status: RESOLVED DUPLICATE of bug 409753
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.11.3
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-16 08:57 UTC by Mathias Homann
Modified: 2019-07-17 07:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Homann 2019-07-16 08:57:54 UTC
on my desktop workstation, akonadi is configured to use a central mysql database on a database server (~ is on NFS, 'nuff said). Since 5.11.3 akonadi dies after 
the first setup, due to dbinitializer in this configuration not realizng that the DB is already initialized.

STEPS TO REPRODUCE
1. do a fresh akonadi configuration using a mysql database on a different machine via tcp/ip, set up some akonadi agents as usual - imap, webdav calendar, google, etc
2. wait for akonadi to fill with data
3. log out (and maybe restart your desktop workstation to make sure all akonadi processes are stopped)
4. log back in


OBSERVED RESULT
akonadiserver is not running

EXPECTED RESULT
akonadiserver should be running


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.16.3
KDE Frameworks Version: 5.59.0
Qt Version: 5.13.0

ADDITIONAL INFORMATION
when running "akonadiserver --verbose" on a commandline:
lemmy@kumiko:~> akonadiserver --verbose
org.kde.pim.akonadiserver: Akonadi control process not found - aborting.
org.kde.pim.akonadiserver: If you started akonadiserver manually, try 'akonadictl start' instead.
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: Found mysql_install_db:  "/usr/bin/mysql_install_db"
org.kde.pim.akonadiserver: Found mysqlcheck:  "/usr/bin/mysqlcheck"
org.kde.pim.akonadiserver: Using mysqld: "/usr/sbin/mysqld"
org.kde.pim.akonadiserver: Database "lemmy_akonadi" opened using driver "QMYSQL"
org.kde.pim.akonadiserver: Running DB initializer
org.kde.pim.akonadiserver: checking table  "SchemaVersionTable"
org.kde.pim.akonadiserver: "ALTER TABLE SchemaVersionTable ADD COLUMN version INTEGER NOT NULL DEFAULT 0"
org.kde.pim.akonadiserver: "\nSql error: Duplicate column name 'version' QMYSQL: Unable to execute query\nQuery: ALTER TABLE SchemaVersionTable ADD COLUMN version INTEGER NOT NULL DEFAULT 0"
org.kde.pim.akonadiserver: Unable to initialize database.
org.kde.pim.akonadiserver: terminating connection threads
org.kde.pim.akonadiserver: terminating service threads
org.kde.pim.akonadiserver: Shutting down "NotificationManager" ...
org.kde.pim.akonadiserver: stopping db process
lemmy@kumiko:~> akonadiserver --version
akonadiserver 5.11.3
lemmy@kumiko:~>


Observe the dbinitializer trying to add a column to a table where that column already exists.
Comment 1 Mathias Homann 2019-07-16 09:57:18 UTC
this completely breaks all pim functionality for existing setups - I don't think this should be "normal"
Comment 2 Christophe Marin 2019-07-16 11:31:05 UTC
critical is used for very specific bugs.
Comment 3 Wolfgang Bauer 2019-07-16 15:25:14 UTC
Looks similar to bug#409753.

Seems to be caused by the PostgreSQL fix.
Comment 4 Mathias Homann 2019-07-17 07:39:32 UTC
yep, it's the same bug.

*** This bug has been marked as a duplicate of bug 409753 ***