Re: Problems with the last update to akonadi [Solved]

[Rex Dieter]

On 04/14/2014 05:56 AM, Laurent Rineau wrote:
> Le Monday 14 April 2014 10:13:20 José Matos a écrit :
> > On Thursday 10 April 2014 23:29:57 José Matos wrote:
> > > Hi Daniel,
> > >   the akonadi server seems to be trapped in a continuous loop. If I
> > >
> > > kill one another one is started. So it is not obvious how to proceed.
> > >
> > > Looking to top I notice that there is a mysqld process running for 55
> > > min (the computer is now up for 7h24m).
> > >
> > > This seems to be the same pattern of yesterday.
> >
> > Just a followup, in case anyone has the same problem.
> >
> > I have solved this last Thursday with Daniel's help.
> >
> > The culprit was:
> >
> > Sql error: The total number of locks exceeds the lock table size QMYSQL:
> > Unable to execute query
> > Query: ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId) REFERENCES
> > PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
> >
> > and the solution was, since I am using an internal mysql server, was to
> > increase the value of the innodb_buffer_pool_size parameter on
> > ~/.local/share/akonadi/mysql.conf
> >
> > The value that was there was of 8M and I have set it to 128M.
>
> I was impacted by that bug too, but I did not found the correct fix. I removed
> my Akonadi database last Friday.
>
> I think that should be reported to upstream KDE, so that they find a way to
> smooth the upgrade.

As a downstream/packaging issue, fedoras akonadi packaging currently 
opts to default to using the values in:
/etc/akonadi/mysql-global-mobile.conf
and not
/etc/akonadi/mysql-global-big.conf
(ie, compare each to /etc/aknoadi/mysql-global.conf)

The rationale being that the -big config, well, was *too* big, 
especially for casual users.  Perhaps we will have to rethink that.

In the meantime, yes, if the values in -mobile are problematic, then 
upstream should also consider adjusting things too.

-- Rex

Problems with the last update to akonadi [Solved]

[Dan Vratil]

On Monday 14 of April 2014 06:02:49 Rex Dieter wrote:
> On 04/14/2014 05:56 AM, Laurent Rineau wrote:
> > Le Monday 14 April 2014 10:13:20 José Matos a écrit :
> > > On Thursday 10 April 2014 23:29:57 José Matos wrote:
> > > > Hi Daniel,
> > > >   the akonadi server seems to be trapped in a continuous loop. If I
> > > >
> > > > kill one another one is started. So it is not obvious how to proceed.
> > > >
> > > > Looking to top I notice that there is a mysqld process running for 55
> > > > min (the computer is now up for 7h24m).
> > > >
> > > > This seems to be the same pattern of yesterday.
> > >
> > > Just a followup, in case anyone has the same problem.
> > >
> > > I have solved this last Thursday with Daniel's help.
> > >
> > > The culprit was:
> > >
> > > Sql error: The total number of locks exceeds the lock table size QMYSQL:
> > > Unable to execute query
> > > Query: ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId) REFERENCES
> > > PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
> > >
> > > and the solution was, since I am using an internal mysql server, was to
> > > increase the value of the innodb_buffer_pool_size parameter on
> > > ~/.local/share/akonadi/mysql.conf
> > >
> > > The value that was there was of 8M and I have set it to 128M.
> >
> > I was impacted by that bug too, but I did not found the correct fix. I
> > removed my Akonadi database last Friday.
> >
> > I think that should be reported to upstream KDE, so that they find a way
> > to
> > smooth the upgrade.

Hi,
> As a downstream/packaging issue, fedoras akonadi packaging currently
> opts to default to using the values in:
> /etc/akonadi/mysql-global-mobile.conf
> and not
> /etc/akonadi/mysql-global-big.conf
> (ie, compare each to /etc/aknoadi/mysql-global.conf)
>
> The rationale being that the -big config, well, was *too* big,
> especially for casual users.  Perhaps we will have to rethink that.

Upstream doesn't think that 80MB innodb_buffer_pool_size is too big :-) and is 
in favor of using mysql-global.conf by default (as shown above, there's a 
reason for those values).  Upstream is actually not surprised that so many 
people complain about poor Akonadi performance, since they are all using what 
could be called a misconfigured database. innodb_buffer_pool_size is one of 
the most critical values for us that directly impact performance of queries 
and IO. I admit it's partly my fault for not noticing this when I took over 
the package, but it never occur to me someone would willingly used the 
crippled config :-)

Unless someone has a *real* reason not to do it, I'm going to switch to the 
-not-really-that-big config in our packages.
> In the meantime, yes, if the values in -mobile are problematic, then
> upstream should also consider adjusting things too.

The -mobile config assumes a device with limited HW resources, where so small 
innodb_buffer_pool_size actually makes sense. This is however not the case on 
desktop.

With my Akonadi maintainer hat on, I think that we should actually remove this 
config now, since it's not tested at all and there's no real usecase for 
Akonadi on mobile device ATM. With my latest fixes to our fork of the SQLite 
driver, using SQLite backend should be much less pain and notably faster, so 
we can recommend mobile distributions to opt-in for SQLite.

Cheers,
Dan
> -- Rex
> _______________________________________________
> kde mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/kde
> New to KDE4? - get help from http://userbase.kde.org

Problems with the last update to akonadi [Solved]

[Markus Slopianka]

On Tuesday 15 April 2014 15:22:42 Daniel Vrátil wrote:
> With my Akonadi maintainer hat on, I think that we should actually remove
> this config now, since it's not tested at all and there's no real usecase
> for Akonadi on mobile device ATM.

Yes, please. As far as I understand this, this would mean that current users 
do not have to change the value manually, i.e. it's a usabulity improvement.
> With my latest fixes to our fork of the
> SQLite driver, using SQLite backend should be much less pain and notably
> faster, so we can recommend mobile distributions to opt-in for SQLite.

Cool

Problems with the last update to akonadi [Solved]

[Ernesto Manríquez Mendoza]

El Mar 15 Abr 2014 15:22:42 Daniel Vrátil escribió:
> On Monday 14 of April 2014 06:02:49 Rex Dieter wrote:
> > On 04/14/2014 05:56 AM, Laurent Rineau wrote:
> > > Le Monday 14 April 2014 10:13:20 José Matos a écrit :
> > > > On Thursday 10 April 2014 23:29:57 José Matos wrote:
> > > > > Hi Daniel,
> > > > >   the akonadi server seems to be trapped in a continuous loop. 

If
> > > > >   I
> > > > >
> > > > > kill one another one is started. So it is not obvious how to

proceed.
> > > > > Looking to top I notice that there is a mysqld process running for

55
> > > > > min (the computer is now up for 7h24m).
> > > > >
> > > > > This seems to be the same pattern of yesterday.
> > > >
> > > > Just a followup, in case anyone has the same problem.
> > > >
> > > > I have solved this last Thursday with Daniel's help.
> > > >
> > > > The culprit was:
> > > >
> > > > Sql error: The total number of locks exceeds the lock table size
> > > > QMYSQL:
> > > > Unable to execute query
> > > > Query: ALTER TABLE PartTable ADD FOREIGN KEY (pimItemId)

REFERENCES
> > > > PimItemTable(id) ON UPDATE CASCADES ON DELETE CASCADE
> > > >
> > > > and the solution was, since I am using an internal mysql server,

was to
> > > > increase the value of the innodb_buffer_pool_size parameter on
> > > > ~/.local/share/akonadi/mysql.conf
> > > >
> > > > The value that was there was of 8M and I have set it to 128M.
> > >
> > > I was impacted by that bug too, but I did not found the correct fix. I
> > > removed my Akonadi database last Friday.
> > >
> > > I think that should be reported to upstream KDE, so that they find a

way
> > > to
> > > smooth the upgrade.
>
> Hi,
> > As a downstream/packaging issue, fedoras akonadi packaging

currently
> > opts to default to using the values in:
> > /etc/akonadi/mysql-global-mobile.conf
> > and not
> > /etc/akonadi/mysql-global-big.conf
> > (ie, compare each to /etc/aknoadi/mysql-global.conf)
> >
> > The rationale being that the -big config, well, was *too* big,
> > especially for casual users.  Perhaps we will have to rethink that.
>
> Upstream doesn't think that 80MB innodb_buffer_pool_size is too big :-)

and
> is in favor of using mysql-global.conf by default (as shown above,

there's
> a reason for those values).  Upstream is actually not surprised that so
> many people complain about poor Akonadi performance, since they are

all
> using what could be called a misconfigured database.
> innodb_buffer_pool_size is one of the most critical values for us that
> directly impact performance of queries and IO. I admit it's partly my

fault
> for not noticing this when I took over the package, but it never occur to
> me someone would willingly used the crippled config :-)
>
> Unless someone has a *real* reason not to do it, I'm going to switch to

the
> -not-really-that-big config in our packages.
> > In the meantime, yes, if the values in -mobile are problematic, then
> > upstream should also consider adjusting things too.
>
> The -mobile config assumes a device with limited HW resources, where

so
> small innodb_buffer_pool_size actually makes sense. This is however

not the
> case on desktop.
>
> With my Akonadi maintainer hat on, I think that we should actually

remove
> this config now, since it's not tested at all and there's no real usecase
> for Akonadi on mobile device ATM. With my latest fixes to our fork of

the
> SQLite driver, using SQLite backend should be much less pain and

notably
> faster, so we can recommend mobile distributions to opt-in for SQLite.
>
> Cheers,
> Dan
> > -- Rex
> > _______________________________________________
> > kde mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/kde
> > New to KDE4? - get help from http://userbase.kde.org

My *real* reason to not use the /etc/akonadi/mysql-global-big.conf is a 
stream of crashes. Daniel, is it possible to make a mysql.conf file tailored 
for Akonadi?

Problems with the last update to akonadi [Solved]

[Dan Vratil]

On Tuesday 15 of April 2014 12:09:05 Ernesto Manríquez Mendoza wrote:
<snip>
> My *real* reason to not use the /etc/akonadi/mysql-global-big.conf is a
> stream of crashes. Daniel, is it possible to make a mysql.conf file tailored
> for Akonadi?

We have some Akonadi-specific modifications to the config file, but other than 
that, we don't need anything special, we can pretty much work with stock 
config.

However your description of problem is not very helpful, try providing more 
details on "stream of crashes", then we can do something about it.

Dan

Problems with the last update to akonadi [Solved]

[Ernesto Manríquez Mendoza]

El Miércoles 16 de abril de 2014 12:59:06 Daniel Vrátil escribió:
> On Tuesday 15 of April 2014 12:09:05 Ernesto Manríquez Mendoza wrote:
>
> <snip>
> > My *real* reason to not use the /etc/akonadi/mysql-global-big.conf is a
> > stream of crashes. Daniel, is it possible to make a mysql.conf file
> > tailored for Akonadi?
>
> We have some Akonadi-specific modifications to the config file, but other
> than that, we don't need anything special, we can pretty much work with
> stock config.
>
> However your description of problem is not very helpful, try providing more
> details on "stream of crashes", then we can do something about it.
>
> Dan

Sorry about being unhelpful, Dan. Here's my backtrace. I installed all 
possible debug symbols using # debuginfo-install akonadi before making Akonadi 
crash, so, if there are missing debug symbols, please give me further 
instructions about how can I get them.

elyria@hydragiros akonadi$ mv mysql.conf mysqlconf.old
elyria@hydragiros akonadi$ cp /etc/akonadi/mysql-global-big.conf mysql.conf
elyria@hydragiros akonadi$ akonadictl start
Starting Akonadi Server... 
   done. 
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
elyria@hydragiros akonadi$ search paths:  ("/usr/lib64/qt-3.3/bin", 
"/usr/local/bin", "/usr/bin", "/bin", "/usr/games", "/usr/local/sbin", 
"/usr/sbin", "/home/elyria/.local/bin", "/home/elyria/bin", "/usr/sbin", 
"/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", 
"/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 
Found mysql_install_db:  "/usr/bin/mysql_install_db" 
Found mysqlcheck:  "/usr/bin/mysqlcheck" 
Database process exited unexpectedly during initial connection!
executable: "/usr/libexec/mysqld"
arguments: ("--defaults-file=/home/elyria/.local/share/akonadi/mysql.conf", "--
datadir=/home/elyria/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-
elyria.rGKeYj/mysql.socket")
stdout: ""
stderr: ""
exit code: 1
process error: "Unknown error"
"[
0: akonadiserver(_Z11akBacktracev+0x4a) [0x465bea]
1: akonadiserver() [0x465e62]
2: /lib64/libc.so.6() [0x3a28435cb0]
3: /lib64/libc.so.6(gsignal+0x39) [0x3a28435c39]
4: /lib64/libc.so.6(abort+0x148) [0x3a28437348]
5: /lib64/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x84) 
[0x366a471d04]
6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xad) [0x467cad]
7: /lib64/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xb0) [0x366a510fb0]
8: /lib64/libQtCore.so.4() [0x366a520c85]
9: /lib64/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x31) [0x366a529e51]
10: 
akonadiserver(_ZN7Akonadi6Server13DbConfigMysql19startInternalServerEv+0x1d29) 
[0x5028a9]
11: 
akonadiserver(_ZN7Akonadi6Server13AkonadiServer20startDatabaseProcessEv+0xff) 
[0x46881f]
12: akonadiserver(_ZN7Akonadi6Server13AkonadiServer4initEv+0xb8) [0x46b128]
13: /lib64/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x26e) [0x366a59febe]
14: 
/lib64/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8d) 
[0x366a586ebd]
15: 
/lib64/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x205) 
[0x366a58a0d5]
16: /lib64/libQtCore.so.4() [0x366a5b6253]
17: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x166) [0x3a2b0492a6]
18: /lib64/libglib-2.0.so.0() [0x3a2b049628]
19: /lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x3a2b0496dc]
20: 
/lib64/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x65) 
[0x366a5b5ad5]
21: 
/lib64/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x3f) 
[0x366a58595f]
22: 
/lib64/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x19d) 
[0x366a585cad]
23: /lib64/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99) [0x366a58b399]
24: akonadiserver(main+0x263) [0x460063]
25: /lib64/libc.so.6(__libc_start_main+0xf5) [0x3a28421d65]
26: akonadiserver() [0x4609d9]
]
"
ProcessControl: Application 'akonadiserver' returned with exit code 255 
(Unknown error)

Problems with the last update to akonadi [Solved]

[Dan Vratil]

On Wednesday 16 of April 2014 05:26:03 Ernesto Manríquez Mendoza wrote:
> El Miércoles 16 de abril de 2014 12:59:06 Daniel Vrátil escribió:
> > On Tuesday 15 of April 2014 12:09:05 Ernesto Manríquez Mendoza wrote:
> >
> > <snip>
> > > My *real* reason to not use the /etc/akonadi/mysql-global-big.conf is a
> > > stream of crashes. Daniel, is it possible to make a mysql.conf file
> > > tailored for Akonadi?
> >
> > We have some Akonadi-specific modifications to the config file, but other
> > than that, we don't need anything special, we can pretty much work with
> > stock config.
> >
> > However your description of problem is not very helpful, try providing
> > more
> > details on "stream of crashes", then we can do something about it.
> >
> > Dan
>
> Sorry about being unhelpful, Dan. Here's my backtrace. I installed all
> possible debug symbols using # debuginfo-install akonadi before making
> Akonadi crash, so, if there are missing debug symbols, please give me
> further instructions about how can I get them.
>
> elyria@hydragiros akonadi$ mv mysql.conf mysqlconf.old
> elyria@hydragiros akonadi$ cp /etc/akonadi/mysql-global-big.conf mysql.conf
> elyria@hydragiros akonadi$ akonadictl start
> Starting Akonadi Server...
>    done.
> Connecting to deprecated signal
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> elyria@hydragiros akonadi$ search paths:  ("/usr/lib64/qt-3.3/bin",
> "/usr/local/bin", "/usr/bin", "/bin", "/usr/games", "/usr/local/sbin",
> "/usr/sbin", "/home/elyria/.local/bin", "/home/elyria/bin", "/usr/sbin",
> "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec",
> "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
> Found mysql_install_db:  "/usr/bin/mysql_install_db"
> Found mysqlcheck:  "/usr/bin/mysqlcheck"
> Database process exited unexpectedly during initial connection!
> executable: "/usr/libexec/mysqld"
> arguments: ("--defaults-file=/home/elyria/.local/share/akonadi/mysql.conf",
> "-- datadir=/home/elyria/.local/share/akonadi/db_data/",
> "--socket=/tmp/akonadi- elyria.rGKeYj/mysql.socket")
> stdout: ""
> stderr: ""
> exit code: 1
> process error: "Unknown error"

This means that the database has failed to start for some reason. Please check 
~/.local/share/akonadi/db_data/mysql.err, there should be more details from 
MySQL on why it failed to start.

Dan
> kde mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/kde
> New to KDE4? - get help from http://userbase.kde.org

Problems with the last update to akonadi [Solved]

[Ernesto Manríquez Mendoza]

El Miércoles 16 de abril de 2014 15:35:27 Daniel Vrátil escribió:
> On Wednesday 16 of April 2014 05:26:03 Ernesto Manríquez Mendoza wrote:
> > El Miércoles 16 de abril de 2014 12:59:06 Daniel Vrátil escribió:
> > > On Tuesday 15 of April 2014 12:09:05 Ernesto Manríquez Mendoza wrote:
> > >
> > > <snip>
> > > > My *real* reason to not use the /etc/akonadi/mysql-global-big.conf is
> > > > a
> > > > stream of crashes. Daniel, is it possible to make a mysql.conf file
> > > > tailored for Akonadi?
> > >
> > > We have some Akonadi-specific modifications to the config file, but
> > > other
> > > than that, we don't need anything special, we can pretty much work with
> > > stock config.
> > >
> > > However your description of problem is not very helpful, try providing
> > > more
> > > details on "stream of crashes", then we can do something about it.
> > >
> > > Dan
> >
> > Sorry about being unhelpful, Dan. Here's my backtrace. I installed all
> > possible debug symbols using # debuginfo-install akonadi before making
> > Akonadi crash, so, if there are missing debug symbols, please give me
> > further instructions about how can I get them.
> >
> > elyria@hydragiros akonadi$ mv mysql.conf mysqlconf.old
> > elyria@hydragiros akonadi$ cp /etc/akonadi/mysql-global-big.conf
> > mysql.conf
> > elyria@hydragiros akonadi$ akonadictl start
> > Starting Akonadi Server...
> >
> > done.
> >
> > Connecting to deprecated signal
> > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> > elyria@hydragiros akonadi$ search paths:  ("/usr/lib64/qt-3.3/bin",
> > "/usr/local/bin", "/usr/bin", "/bin", "/usr/games", "/usr/local/sbin",
> > "/usr/sbin", "/home/elyria/.local/bin", "/home/elyria/bin", "/usr/sbin",
> > "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec",
> > "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
> > Found mysql_install_db:  "/usr/bin/mysql_install_db"
> > Found mysqlcheck:  "/usr/bin/mysqlcheck"
> > Database process exited unexpectedly during initial connection!
> > executable: "/usr/libexec/mysqld"
> > arguments:
> > ("--defaults-file=/home/elyria/.local/share/akonadi/mysql.conf",
> > "-- datadir=/home/elyria/.local/share/akonadi/db_data/",
> > "--socket=/tmp/akonadi- elyria.rGKeYj/mysql.socket")
> > stdout: ""
> > stderr: ""
> > exit code: 1
> > process error: "Unknown error"
>
> This means that the database has failed to start for some reason. Please
> check ~/.local/share/akonadi/db_data/mysql.err, there should be more
> details from MySQL on why it failed to start.
>
> Dan
> > kde mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/kde
> > New to KDE4? - get help from http://userbase.kde.org

~/.local/share/akonadi/db_data/mysql.err

140416  9:22:55 InnoDB: The InnoDB memory heap is disabled
140416  9:22:55 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140416  9:22:55 InnoDB: Compressed tables use zlib 1.2.8
140416  9:22:55 InnoDB: Using Linux native AIO
140416  9:22:55 InnoDB: Initializing buffer pool, size = 80.0M
140416  9:22:55 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 2097152 bytes
InnoDB: than specified in the .cnf file 0 67108864 bytes!
140416  9:22:55 [ERROR] Plugin 'InnoDB' init function returned error.
140416  9:22:55 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE 
failed.
140416  9:22:55 [Note] Plugin 'FEEDBACK' is disabled.
140416  9:22:55 [ERROR] Unknown/unsupported storage engine: innodb
140416  9:22:55 [ERROR] Aborting

140416  9:22:55 [Note] /usr/libexec/mysqld: Shutdown complete

Problems with the last update to akonadi [Solved]

[Piotr Gbyliczek]

On Wednesday 16 Apr 2014 05:26:03 Ernesto Manríquez Mendoza wrote:
> elyria@hydragiros akonadi$ mv mysql.conf mysqlconf.old
> elyria@hydragiros akonadi$ cp /etc/akonadi/mysql-global-big.conf mysql.conf
> elyria@hydragiros akonadi$ akonadictl start
> Starting Akonadi Server...
>    done.
> Connecting to deprecated signal
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> elyria@hydragiros akonadi$ search paths:  ("/usr/lib64/qt-3.3/bin",
> "/usr/local/bin", "/usr/bin", "/bin", "/usr/games", "/usr/local/sbin",
> "/usr/sbin", "/home/elyria/.local/bin", "/home/elyria/bin", "/usr/sbin",
> "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec",
> "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
> Found mysql_install_db:  "/usr/bin/mysql_install_db"
> Found mysqlcheck:  "/usr/bin/mysqlcheck"
> Database process exited unexpectedly during initial connection!
> executable: "/usr/libexec/mysqld"
> arguments: ("--defaults-file=/home/elyria/.local/share/akonadi/mysql.conf",
> "-- datadir=/home/elyria/.local/share/akonadi/db_data/",
> "--socket=/tmp/akonadi- elyria.rGKeYj/mysql.socket")
> stdout: ""
> stderr: ""
> exit code: 1
> process error: "Unknown error"
> ProcessControl: Application 'akonadiserver' returned with exit code 255

I have the same thing with mysql-global-big.conf replacing the one that I'm 
using right now (presumably a copy of mysql-global-mobile.conf), but can see 
only two lines being different between them :

46c46
< innodb_buffer_pool_size=80M
---
> innodb_buffer_pool_size=8M

59c59
< innodb_log_file_size=64M
---
> innodb_log_file_size=2M

I bet the error log is saying something about innodb logs being different size 
than configured, because every time I was in situation to set 
innodb_log_file_size, I had to remove ib_logfile* and let mysql recreate it 
fresh.

In fact, I've just raised buffer pool to 80M and no crash at start.

Problems with the last update to akonadi [Solved]

[Ernesto Manríquez Mendoza]

El Miércoles 16 de abril de 2014 15:05:34 Piotr Gbyliczek escribió:
> On Wednesday 16 Apr 2014 05:26:03 Ernesto Manríquez Mendoza wrote:
> > elyria@hydragiros akonadi$ mv mysql.conf mysqlconf.old
> > elyria@hydragiros akonadi$ cp /etc/akonadi/mysql-global-big.conf
> > mysql.conf
> > elyria@hydragiros akonadi$ akonadictl start
> > Starting Akonadi Server...
> >
> > done.
> >
> > Connecting to deprecated signal
> > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> > elyria@hydragiros akonadi$ search paths:  ("/usr/lib64/qt-3.3/bin",
> > "/usr/local/bin", "/usr/bin", "/bin", "/usr/games", "/usr/local/sbin",
> > "/usr/sbin", "/home/elyria/.local/bin", "/home/elyria/bin", "/usr/sbin",
> > "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec",
> > "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin")
> > Found mysql_install_db:  "/usr/bin/mysql_install_db"
> > Found mysqlcheck:  "/usr/bin/mysqlcheck"
> > Database process exited unexpectedly during initial connection!
> > executable: "/usr/libexec/mysqld"
> > arguments:
> > ("--defaults-file=/home/elyria/.local/share/akonadi/mysql.conf",
> > "-- datadir=/home/elyria/.local/share/akonadi/db_data/",
> > "--socket=/tmp/akonadi- elyria.rGKeYj/mysql.socket")
> > stdout: ""
> > stderr: ""
> > exit code: 1
> > process error: "Unknown error"
> > ProcessControl: Application 'akonadiserver' returned with exit code 255
>
> I have the same thing with mysql-global-big.conf replacing the one that I'm
> using right now (presumably a copy of mysql-global-mobile.conf), but can see
> only two lines being different between them :
>
> 46c46
> < innodb_buffer_pool_size=80M
> > innodb_buffer_pool_size=8M
>
> 59c59
> < innodb_log_file_size=64M
> > innodb_log_file_size=2M
>
> I bet the error log is saying something about innodb logs being different
> size than configured, because every time I was in situation to set
> innodb_log_file_size, I had to remove ib_logfile* and let mysql recreate it
> fresh.
>
> In fact, I've just raised buffer pool to 80M and no crash at start.

Exactly that.

I'll do what you say, thanks!