Bug 326480 - Akonadi fails to start with nvidia binary drivers installed
Summary: Akonadi fails to start with nvidia binary drivers installed
Status: RESOLVED UPSTREAM
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 4.10
Platform: Mageia RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL: http://forum.kde.org/viewtopic.php?f=...
Keywords:
: 327159 327411 328119 328201 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-10-23 04:34 UTC by Dimitrios Glentadakis
Modified: 2014-01-29 01:06 UTC (History)
37 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
libakonadi debug output (2.43 KB, text/plain)
2013-11-10 13:29 UTC, Graeme Hewson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitrios Glentadakis 2013-10-23 04:34:30 UTC
Since 1 month, akonadi fails to start after boot
I deleted the content of the folders .local/share/akonadi and .configure/akonadi, it works for a few days and after it stops again

Reproducible: Always

Steps to Reproduce:
After boot
Actual Results:  
Akonadi doesn't start

Expected Results:  
Akonadi start up

Akonadi Server Self-Test Report
===============================

Test 1: SUCCESS
--------

Database driver found.
Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system.

File content of '/home/dglent/.config/akonadi/akonadiserverrc':
[%General]
Driver=QMYSQL

[QMYSQL]
Name=akonadi
Host=
Options="UNIX_SOCKET=/home/dglent/.local/share/akonadi/socket-localhost.localdomain/mysql.socket"
ServerPath=/usr/sbin/mysqld
StartServer=true

[Debug]
Tracer=null


Test 2: SUCCESS
--------

Akonadi is not running as root
Details: Akonadi is not running as a root/administrator user, which is the recommended setup for a secure system.

Test 3: SUCCESS
--------

MySQL server found.
Details: You have currently configured Akonadi to use the MySQL server '/usr/sbin/mysqld'.
Make sure you have the MySQL server installed, set the correct path and ensure you have the necessary read and execution rights on the server executable. The server executable is typically called 'mysqld'; its location varies depending on the distribution.

Test 4: SUCCESS
--------

MySQL server is executable.
Details: MySQL server found: 131019 14:08:14 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
/usr/sbin/mysqld Ver 5.5.33a-MariaDB for Linux on x86_64 (Mageia MariaDB Server)


Test 5: SUCCESS
--------

MySQL server log contains no errors.
Details: The MySQL server log file &apos;<a href='/home/dglent/.local/share/akonadi/db_data/mysql.err'>/home/dglent/.local/share/akonadi/db_data/mysql.err</a>&apos; does not contain any errors or warnings.

File content of '/home/dglent/.local/share/akonadi/db_data/mysql.err':
131019 13:59:17 InnoDB: The InnoDB memory heap is disabled
131019 13:59:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131019 13:59:17 InnoDB: Compressed tables use zlib 1.2.7
131019 13:59:17 InnoDB: Using Linux native AIO
131019 13:59:17 InnoDB: Initializing buffer pool, size = 80.0M
131019 13:59:17 InnoDB: Completed initialization of buffer pool
131019 13:59:17 InnoDB: highest supported file format is Barracuda.
131019 13:59:18 InnoDB: Waiting for the background threads to start
131019 13:59:19 Percona XtraDB (http://www.percona.com) 5.5.33a-MariaDB-31.1 started; log sequence number 21404448
131019 13:59:19 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.33a-MariaDB' socket: '/home/dglent/.local/share/akonadi/socket-localhost.localdomain/mysql.socket' port: 0 Mageia MariaDB Server


Test 6: SUCCESS
--------

MySQL server default configuration found.
Details: The default configuration for the MySQL server was found and is readable at <a href='/etc/akonadi/mysql-global.conf'>/etc/akonadi/mysql-global.conf</a>.

File content of '/etc/akonadi/mysql-global.conf':
#
# Global Akonadi MySQL server settings,
# These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf
#
# Based on advice by Kris Köhntopp <kris@mysql.com>
#
[mysqld]

# strict query parsing/interpretation
# TODO: make Akonadi work with those settings enabled
# sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat
# sql_mode=strict_trans_tables

# DEBUGGING:
# log all queries, useful for debugging but generates an enormous amount of data
# log=mysql.full
# log queries slower than n seconds, log file name relative to datadir (for debugging only)
# log_slow_queries=mysql.slow
# long_query_time=1
# log queries not using indices, debug only, disable for production use
# log_queries_not_using_indexes=1
#
# mesure database size and adjust innodb_buffer_pool_size
# SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema");

# NOTES:
# Keep Innob_log_waits and keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables)

#expire_logs_days=3

#sync_bin_log=0

# Use UTF-8 encoding for tables
character_set_server=utf8
collation_server=utf8_general_ci

# use InnoDB for transactions and better crash recovery
default_storage_engine=innodb

# memory pool InnoDB uses to store data dictionary information and other internal data structures (default:1M)
innodb_additional_mem_pool_size=1M

# memory buffer InnoDB uses to cache data and indexes of its tables (default:128M)
# Larger values means less I/O
innodb_buffer_pool_size=80M

# Create a .ibd file for each table (default:0)
innodb_file_per_table=1

# Write out the log buffer to the log file at each commit (default:1)
innodb_flush_log_at_trx_commit=2

# Buffer size used to write to the log files on disk (default:1M for builtin, 8M for plugin)
# larger values means less I/O
innodb_log_buffer_size=1M

# Size of each log file in a log group (default:5M) larger means less I/O but more time for recovery.
innodb_log_file_size=64M

# # error log file name, relative to datadir (default:hostname.err)
log_error=mysql.err

# print warnings and connection errors (default:1)
log_warnings=2

# Convert table named to lowercase
lower_case_table_names=1

# Maximum size of one packet or any generated/intermediate string. (default:1M)
max_allowed_packet=32M

# Maximum simultaneous connections allowed (default:100)
max_connections=256

# The two options below make no sense with prepared statements and/or transactions
# (make sense when having the same query multiple times)

# Memory allocated for caching query results (default:0 (disabled))
query_cache_size=0

# Do not cache results (default:1)
query_cache_type=0

# Do not use the privileges mechanisms
skip_grant_tables

# Do not listen for TCP/IP connections at all
skip_networking

# The number of open tables for all threads. (default:64)
table_cache=200

# How many threads the server should cache for reuse (default:0)
thread_cache_size=3

# wait 365d before dropping the DB connection (default:8h)
wait_timeout=31536000

[client]
default-character-set=utf8


Test 7: SKIP
--------

MySQL server custom configuration not available.
Details: The custom configuration for the MySQL server was not found but is optional.

Test 8: SUCCESS
--------

MySQL server configuration is usable.
Details: The MySQL server configuration was found at <a href='/home/dglent/.local/share/akonadi/mysql.conf'>/home/dglent/.local/share/akonadi/mysql.conf</a> and is readable.

File content of '/home/dglent/.local/share/akonadi/mysql.conf':
#
# Global Akonadi MySQL server settings,
# These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf
#
# Based on advice by Kris Köhntopp <kris@mysql.com>
#
[mysqld]

# strict query parsing/interpretation
# TODO: make Akonadi work with those settings enabled
# sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat
# sql_mode=strict_trans_tables

# DEBUGGING:
# log all queries, useful for debugging but generates an enormous amount of data
# log=mysql.full
# log queries slower than n seconds, log file name relative to datadir (for debugging only)
# log_slow_queries=mysql.slow
# long_query_time=1
# log queries not using indices, debug only, disable for production use
# log_queries_not_using_indexes=1
#
# mesure database size and adjust innodb_buffer_pool_size
# SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema");

# NOTES:
# Keep Innob_log_waits and keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables)

#expire_logs_days=3

#sync_bin_log=0

# Use UTF-8 encoding for tables
character_set_server=utf8
collation_server=utf8_general_ci

# use InnoDB for transactions and better crash recovery
default_storage_engine=innodb

# memory pool InnoDB uses to store data dictionary information and other internal data structures (default:1M)
innodb_additional_mem_pool_size=1M

# memory buffer InnoDB uses to cache data and indexes of its tables (default:128M)
# Larger values means less I/O
innodb_buffer_pool_size=80M

# Create a .ibd file for each table (default:0)
innodb_file_per_table=1

# Write out the log buffer to the log file at each commit (default:1)
innodb_flush_log_at_trx_commit=2

# Buffer size used to write to the log files on disk (default:1M for builtin, 8M for plugin)
# larger values means less I/O
innodb_log_buffer_size=1M

# Size of each log file in a log group (default:5M) larger means less I/O but more time for recovery.
innodb_log_file_size=64M

# # error log file name, relative to datadir (default:hostname.err)
log_error=mysql.err

# print warnings and connection errors (default:1)
log_warnings=2

# Convert table named to lowercase
lower_case_table_names=1

# Maximum size of one packet or any generated/intermediate string. (default:1M)
max_allowed_packet=32M

# Maximum simultaneous connections allowed (default:100)
max_connections=256

# The two options below make no sense with prepared statements and/or transactions
# (make sense when having the same query multiple times)

# Memory allocated for caching query results (default:0 (disabled))
query_cache_size=0

# Do not cache results (default:1)
query_cache_type=0

# Do not use the privileges mechanisms
skip_grant_tables

# Do not listen for TCP/IP connections at all
skip_networking

# The number of open tables for all threads. (default:64)
table_cache=200

# How many threads the server should cache for reuse (default:0)
thread_cache_size=3

# wait 365d before dropping the DB connection (default:8h)
wait_timeout=31536000

[client]
default-character-set=utf8


Test 9: SUCCESS
--------

akonadictl found and usable
Details: The program '/usr/bin/akonadictl' to control the Akonadi server was found and could be executed successfully.
Result:
Akonadi 1.9.1


Test 10: ERROR
--------

Akonadi control process not registered at D-Bus.
Details: The Akonadi control process is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup.

Test 11: ERROR
--------

Akonadi server process not registered at D-Bus.
Details: The Akonadi server process is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup.

Test 12: ERROR
--------

Nepomuk search service not registered at D-Bus.
Details: The Nepomuk search service is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup.

Test 13: SKIP
--------

Protocol version check not possible.
Details: Without a connection to the server it is not possible to check if the protocol version meets the requirements.

Test 14: ERROR
--------

No resource agents found.
Details: No resource agents have been found, Akonadi is not usable without at least one. This usually means that no resource agents are installed or that there is a setup problem. The following paths have been searched: '/usr/share/akonadi/agents'. The XDG_DATA_DIRS environment variable is set to '/usr/share:/usr/share:/usr/local/share'; make sure this includes all paths where Akonadi agents are installed.

Directory listing of '/usr/share/akonadi/agents':
akonadinepomukfeederagent.desktop
akonotesresource.desktop
archivemailagent.desktop
birthdaysresource.desktop
contactsresource.desktop
davgroupwareresource.desktop
facebookresource.desktop
googlecalendarresource.desktop
googlecontactsresource.desktop
icaldirresource.desktop
icalresource.desktop
imapresource.desktop
invitationsagent.desktop
kabcresource.desktop
kalarmdirresource.desktop
kalarmresource.desktop
kcalresource.desktop
kdeaccountsresource.desktop
knutresource.desktop
kolabproxyresource.desktop
localbookmarksresource.desktop
maildirresource.desktop
maildispatcheragent.desktop
mailfilteragent.desktop
mboxresource.desktop
microblog.desktop
mixedmaildirresource.desktop
mtdummyresource.desktop
nepomuktagresource.desktop
nntpresource.desktop
notesresource.desktop
openxchangeresource.desktop
pop3resource.desktop
vcarddirresource.desktop
vcardresource.desktop

Environment variable XDG_DATA_DIRS is set to '/usr/share:/usr/share:/usr/local/share'

Test 15: SUCCESS
--------

No current Akonadi server error log found.
Details: The Akonadi server did not report any errors during its current startup.

Test 16: SUCCESS
--------

No previous Akonadi server error log found.
Details: The Akonadi server did not report any errors during its previous startup.

Test 17: SUCCESS
--------

No current Akonadi control error log found.
Details: The Akonadi control process did not report any errors during its current startup.

Test 18: SUCCESS
--------

No previous Akonadi control error log found.
Details: The Akonadi control process did not report any errors during its previous startup.

Installed packages:

[dglent@localhost ~]$ rpm -qa | grep akonadi
akonadiconsole-4.10.5-1.1.mga3
lib64akonadi-devel-1.9.1-2.mga3
lib64akonadi-xml4-4.10.5-1.1.mga3
lib64akonadi_socialutils4-4.10.5-1.1.mga3
lib64akonadi-kabc4-4.10.5-1.1.mga3
lib64akonadi-notes4-4.10.5-1.1.mga3
lib64akonadi-filestore4-4.10.5-1.1.mga3
lib64akonadi-kde4-4.10.5-1.1.mga3
lib64akonadi-next4-4.10.5-1.1.mga3
lib64akonadi-kmime4-4.10.5-1.1.mga3
lib64akonadi-kcal4-4.10.5-1.1.mga3
lib64akonadi-contact4-4.10.5-1.1.mga3
akonadi-kde-4.10.5-1.1.mga3
lib64akonadiprotocolinternals1-1.9.1-2.mga3
akonadi-1.9.1-2.mga3
lib64akonadi-calendar4-4.10.5-1.1.mga3

[dglent@localhost ~]$ rpm -qa | grep sql
qt4-database-plugin-sqlite-4.8.5-1.2.mga3
qt4-database-plugin-mysql-4.8.5-1.2.mga3
lib64sqlite3-devel-3.8.0.2-1mgr3
postgresql-jdbc-9.2.1002-3.mga3
python-qt4-sql-4.9.6-4.mga3
lib64qtsql4-4.8.5-1.2.mga3
lib64sqlite3_0-3.8.0.2-1mgr3

[dglent@localhost ~]$ rpm -qa | grep maria
mariadb-client-5.5.33a-1.mga3
mariadb-core-5.5.33a-1.mga3
lib64mariadb18-5.5.33a-1.mga3
mariadb-common-5.5.33a-1.mga3
mariadb-common-core-5.5.33a-1.mga3
Comment 1 Daniel Vrátil 2013-10-24 15:26:08 UTC
Can you please provide output of "ps x | grep -i akonadi" ?
Comment 2 Graeme Hewson 2013-10-28 14:23:36 UTC
I have this problem after upgrading Kubuntu 13.04 to 13.10, but not always. Sometimes after rebooting and logging in, Akonadi starts properly, but most often, although akonadi_control and akonadiserver are running, I see the messages in tests 10 and 11:

Akonadi control process not registered at D-Bus.
Akonadi server process not registered at D-Bus.

(Unlike the above log, though, test 12 for me says "Nepomuk search service registered at D-Bus.")

The solution for me is:

pkill akonadi_control
pkill akonadiserver
akonadictl start

I guess it's a timing problem.
Comment 3 Graeme Hewson 2013-10-28 14:25:53 UTC
I forgot to mention that I had the KDE 4.11.2 PPA installed under Kubuntu 13.04, so the KDE version didn't change with the upgrade to 13.10.
Comment 4 Christophe Marin 2013-10-28 14:44:34 UTC
(In reply to comment #3)
> I forgot to mention that I had the KDE 4.11.2 PPA installed under Kubuntu
> 13.04, so the KDE version didn't change with the upgrade to 13.10.

no message from apparmor in the dmesg output ?
can you also check if the mysql version changed when your switched to kubuntu 13.10 ?
are the mysql-upgrade and mysqladmin still installed ?
Comment 5 Graeme Hewson 2013-10-28 15:43:15 UTC
Messages from apparmor are:

apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 parent=1 profile="/usr/sbin/mysqld-akonadi///usr/sbin/mysqld" name=".local/share/akonadi/db_data/mysql.err" pid=2813 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 parent=1 profile="/usr/sbin/mysqld-akonadi///usr/sbin/mysqld" name=".local/share/akonadi/db_data/mysql.err" pid=2813 comm="mysqld" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

Mysql changed from 5.5.32 to 5.5.34.

mysqladmin is installed, but not mysql-upgrade.
Comment 6 Christophe Marin 2013-10-28 18:33:07 UTC
ok, please try:
sudo aa-complain mysqld-akonadi 
sudo /etc/init.d/apparmor reload
akonadictl start
Comment 7 GiovanniES 2013-10-31 19:11:22 UTC
After installing Kubuntu 13.10 from Kubuntu 13.04 I have found the same problem with Akonadi. After deleting ~/.local/share/akonadi and ~/.config/akonadi I could reload the calendar I have in KOrganizer, but the events are not loaded until I restart the session. I too had KDE 4.11.2, but from a PPA, ppa:kubuntu-ppa/backports.

Just today the same happened after several days of normal use.
Comment 8 Graeme Hewson 2013-11-01 10:17:02 UTC
(In reply to comment #6)
> ok, please try:
> sudo aa-complain mysqld-akonadi 
> sudo /etc/init.d/apparmor reload
> akonadictl start

I didn't try this because the apparmor messages haven't reappeared after several reboots. I guess they only appeared because I was struggling to get kmail working after the Kubuntu upgrade.

Still akonadi sometimes starts properly after rebooting and logging in, but mostly it doesn't.
Comment 9 GiovanniES 2013-11-01 18:54:24 UTC
Again Akonadi fail to load. After using
$ pkill akonadi_control
$ pkill akonadiserver
$ akonadictl start
I got this exit
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
search paths:  ("/home/giovanni/bin", "/usr/lib/lightdm/lightdm", "/usr/local/sbin", "/usr/local/bin", "/usr/sbin", "/usr/bin", "/sbin", "/bin", "/usr/games", "/usr/local/games", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 
akonadi.collectionattributetable                   OK
akonadi.collectionmimetyperelation                 OK
akonadi.collectionpimitemrelation                  OK
akonadi.collectiontable                            OK
akonadi.flagtable                                  OK
akonadi.mimetypetable                              OK
akonadi.parttable                                  OK
akonadi.pimitemflagrelation                        OK
akonadi.pimitemtable                               OK
akonadi.resourcetable                              OK
akonadi.schemaversiontable                         OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.servers                                      OK
mysql.slow_log                                     OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
search paths:  ("/home/giovanni/bin", "/usr/lib/lightdm/lightdm", "/usr/local/sbin", "/usr/local/bin", "/usr/sbin", "/usr/bin", "/sbin", "/bin", "/usr/games", "/usr/local/games") 
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
search paths:  ("/home/giovanni/.kde/lib/kde4/plugins/", "/usr/lib/kde4/plugins/", "/usr/lib/x86_64-linux-gnu/qt4/plugins", "/usr/lib/qt4/plugins", "/usr/bin", "/usr/lib/kde4/plugins", "/home/giovanni/.kde/lib/kde4/", "/usr/lib/kde4/") 
search paths:  ("/home/giovanni/.kde/lib/kde4/plugins/", "/usr/lib/kde4/plugins/", "/usr/lib/x86_64-linux-gnu/qt4/plugins", "/usr/lib/qt4/plugins", "/usr/bin", "/usr/lib/kde4/plugins", "/home/giovanni/.kde/lib/kde4/", "/usr/lib/kde4/") 
"Cannot connect to agent instance with identifier 'akonadi_maildir_resource_0', error message: 'Could not get owner of name 'org.freedesktop.Akonadi.Resource.akonadi_maildir_resource_0': no such name'"
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated.
akonadi_nepomuk_feeder(10690) FeederPluginloader::feederPluginsForMimeType: No feeder for type  "text/calendar"  found 
Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.

And it stayed there until I hit enter again. Akonadi is working and I can see my programmed events.
Comment 10 Graeme Hewson 2013-11-02 11:46:07 UTC
I've noticed that akonadi usually starts OK when I log in after being logged in previously for several days. When this happens, nepomuk seems to be working hard (catching up on the work it didn't do in the previous login session?).

Incidentally, in comment 2 I neglected to show a clean shutdown of mysql. The full sequence of commands is:

pkill akonadi_control
pkill akonadiserver
mysqladmin shutdown --socket ~/.local/share/akonadi/socket-$(hostname)/mysql.socket
akonadictl start
Comment 11 Dimitrios Glentadakis 2013-11-02 12:20:33 UTC
The output of ps x | grep -i akonadi:

[dglent@localhost ~]$ ps x | grep -i akonadi
 1673 ?        Sl     0:00 /usr/bin/akonadi_control
 1675 ?        Sl     0:00 akonadiserver
 1677 ?        Sl     0:00 /usr/sbin/mysqld --defaults-file=/home/dglent/.local/share/akonadi/mysql.conf --datadir=/home/dglent/.local/share/akonadi/db_data/ --socket=/home/dglent/.local/share/akonadi/socket-localhost.localdomain/mysql.socket
Comment 12 Dimitrios Glentadakis 2013-11-03 04:59:41 UTC
I can reproduce it with mariadb 5.5.33a but i cannot reproduce it with mariadb-5-5-28.
I will continue the test and i will confirm it later.

I remarked with mariadb 5.5.33a i have the process mysqlcheck as zombie
Comment 13 Dimitrios Glentadakis 2013-11-04 05:30:36 UTC
This morning i had again the symptome with mariadb 5.5.28 :(
Comment 14 Daniel Vrátil 2013-11-04 12:12:44 UTC
The problem appears to be that sometimes (?) Akonadi is unable to start any resources or agents. Akonadi requires at least one agent or resource to run.

Apparently the resources are available (judging from content of /usr/share/akonadi/agents). Please enable ibakonadi in kdebugdialog and start Akonadi from console (akonadictl start) and paste here the output.
Comment 15 Japs 2013-11-05 15:13:39 UTC
*** Bug 327159 has been marked as a duplicate of this bug. ***
Comment 16 Dimitrios Glentadakis 2013-11-07 15:40:50 UTC
The output of akonadictl start:

[dglent@localhost ~]$ akonadictl start
Unable to register service as "org.freedesktop.Akonadi.Control.lock" Maybe it's already running?
"[
0: /usr/bin/akonadi_control(_Z11akBacktracev+0x33) [0x43e943]
1: /usr/bin/akonadi_control() [0x43ec9a]
2: /lib64/libc.so.6(+0x34ae0) [0x7f949291bae0]
3: /lib64/libc.so.6(gsignal+0x35) [0x7f949291ba65]
4: /lib64/libc.so.6(abort+0x148) [0x7f949291d0c8]
5: /lib64/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7f949392a224]
6: /usr/bin/akonadi_control(_ZN15FileDebugStream9writeDataEPKcx+0x9b) [0x440a0b]
7: /lib64/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xb4) [0x7f94939c4af4]
8: /lib64/libQtCore.so.4(+0x11682f) [0x7f94939cf82f]
9: /lib64/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x3b) [0x7f94939d7e2b]
10: /usr/bin/akonadi_control(_ZN6QDebugD1Ev+0x3f) [0x41c48f]
11: /usr/bin/akonadi_control(main+0x350) [0x419230]
12: /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f9492908ba5]
13: /usr/bin/akonadi_control() [0x4193f9]
]
"
Error: akonadi_control was started but didn't register at D-Bus session bus.
Make sure your system is set up correctly!
Comment 17 Graeme Hewson 2013-11-10 13:29:27 UTC
Created attachment 83470 [details]
libakonadi debug output
Comment 18 Graeme Hewson 2013-11-10 13:30:26 UTC
I directed libakonadi debug output to disk while I logged in to KDE (file attached).

The messages make reference to /tmp/akonadi-ghewson.ws0sFY/akonadiserver.socket, but there is no such file. This is after a reboot (on Kubuntu, where /tmp is cleared between reboots). However, the file /did/ exist in the previous session, and in the current session ~/.local/share/akonadi/socket-$(hostname) is a link to /tmp/akonadi-ghewson.ws0sFY/akonadiserver.socket.

The messages also say "Akonadi server is already starting up", but before logging in to KDE I started a terminal session and verified that Akonadi wasn't running. (It's very hard to see how it could have been!)

To reiterate: sometimes Akonadi does start properly. In fact, while I was debugging, it usually did (presumably due to a change in the timing), and I had to try several times before it failed to start properly.
Comment 19 Daniel Vrátil 2013-11-11 16:23:45 UTC
Could any of you please try whether the problem is fixed with this [0] patch for kdepimlibs? The patch addresses a DBus-timing problem that could be the same as yours. I'm just not very happy about how it fixes the problem. We will work on it with Guy this weekend on the PIM sprint and get it to next KDE update.


[0] https://git.reviewboard.kde.org/r/112062/
Comment 20 Tsu Jan 2013-11-29 14:01:06 UTC
*** Bug 328201 has been marked as a duplicate of this bug. ***
Comment 21 Tsu Jan 2013-11-29 15:07:58 UTC
@Daniel Vrátil 
Sadly, the patch didn't fix the problem. After the first reboot, Akonadi started normally but after another reboot, the same issue happened again.
Comment 22 Christian S 2013-11-30 11:40:52 UTC
*** This bug has been confirmed by popular vote. ***
Comment 23 Christian S 2013-11-30 11:49:30 UTC
Hi Guys - I filed one bug report on Kubuntu-launchpad for this bug before we realized that this affects not only Kubuntu users.

I cannot follow any more which of the various things I did changed my situation, but now under KDE 4.11.3 my akonadi almost always starts on booting (not always though, but mostly compared to almost never before). If akonadi fails to start, the three pkill commands mentioned above remedy this problem.

However, if I get akonadi started I now always observe serious CPU consumption of both mysql and akonadi on working with kontact. reading emails and managing them is very slow, but sending is impossible. Kontact always becomes unresponsive and eventually crashed on this step. However, I found an advice to remedy this problem by "cleaning up the profile" and want to give this a try. However, how exactly do I COMPLETELY clean up kontact/akonadi/whatever else profile and start completely clean. No worries about backup here - everything is IMAP and calender is back-uped already.

Thanks
Comment 24 Bartosz Kwitniewski 2013-11-30 12:22:09 UTC
I have moved akonadi database from ~/.local/share/akonadi to another directory few days ago but it didn't help - I still have to kill and start akonadi every time. Note that removing database will at least mess up directories settings (sent, trash, etc. in identities and filters), so filters can move Your mail to more or less random directories.

I have tried patching (https://git.reviewboard.kde.org/r/112062/) - Kmail did start about 15 seconds after logging in and I was able to read mail but I couldn't mark it as read or delete it - as if database became read-only. Also, I still wasn't able to stop and start akonadi from akonaditray - I had to kill it. There are so many corpses laying around.

Arch Linux 64 bit, KDE 4.11.3, KMail 4.11.3, mysql 5.5.30
Comment 25 Tsu Jan 2013-11-30 13:48:37 UTC
I don't know if this info is helpful in debugging but I see such a randomness in some other parts of KDE-4.11 too: Bug 328023, Bug 317894, random crashes in Plasma after log-in, random freezes after changing Desktop Effects with System Settings. Except for Bug 317894, none of them happened in KDE-4.10.
Comment 26 Marcus 2013-12-04 13:44:30 UTC
I have the same problem since updating to Kubuntu 13.10. Since I found the pkill sequence mentioned I use it and it works. But its about 1 of 4 times I start my computer, that akonadi doesn't work. If there is anything I could test, please ask.

I dont know if this is related to the problem: Starting Kontact I often get a message, that kmail incoming email filters missing an mail account to use. It shows a window asking to choose the account,  but all my accounts are not shown. Either I click ok or esc afterwards the filter is deleted in kmail. I was wondering if that is connected to the problem, that akonadi recources doesn't sucessfully announce its service at the dbus.
Comment 27 Marcus 2013-12-06 02:32:26 UTC
I just realized I have another problem, not related to akonadi but to iBus. I use an input method called fcitx for chinese input. After I installed Kubuntu 13.10 it has just the same problem like akonadi-server. It needs to get killed and started again, afterwards just running fine.

Which means, this bug might be wrong here.
Comment 28 Marcus 2013-12-06 02:37:17 UTC
sorry, I meant dBus, not iBus
Comment 29 Bernd Weigelt 2013-12-06 09:32:41 UTC
i see this bug only on one of my systems, my workaround is to kill akonadi_control and akonadiserver, but i have to do this after every reboot.
My system is openSUSE 13.1, updated from 12.3 with 'zypper dup'
Comment 30 Daniel Vrátil 2013-12-07 23:07:12 UTC
Guys, can you please remove (or rename) file  /usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service ? 

I found out that the auto-start does not work (probably because env is not passed correctly with dbus invocation) and in some cases I believe it could lead to the  situation when only akonadi_control and akonadiserver are running with broken dbus services.
Comment 31 Dimitrios Glentadakis 2013-12-08 06:26:09 UTC
I renamed it but it didn't help
The only difference is that now i have a second mysqld process that i have to kill
Comment 32 Graeme Hewson 2013-12-08 10:58:46 UTC
Renaming it didn't work for me, either (though Akonadi successfully came up 4 out 5 times). I only had one mysqld process when it failed though, as before.
Comment 33 Marcus 2013-12-08 11:08:12 UTC
Same here, renaming didn't change anything. After renaming the first start the problem appeared again.
Comment 34 Daniel Vrátil 2013-12-10 11:20:36 UTC
*** Bug 328119 has been marked as a duplicate of this bug. ***
Comment 35 Thomas Dreibholz 2013-12-17 15:07:51 UTC
I have the same problem on a system running Kubuntu 13.10, with KDE 4.11.3 from the Kubuntu Backports PPA.
Comment 36 Andreas Roth 2013-12-19 09:11:09 UTC
just installed KDE 4.12 on kubuntu 13.10 amd64 and the problem still appears. 
sending SIGTERM to all akonadi processes (incl. mysql) and restarting kontact akonadi works again (until restarting the machine).
Comment 37 Bernd Weigelt 2013-12-19 10:12:29 UTC
Hi

i take a look at the process list on my systems, btw found a second system with this problem.
on the systems with this problem the PID of akonadi_control(4858) and akonadiserver (4859) is lower then the PID of dbus-daemon (4702) started by KDE
both systems are updated from openSUSE 12.3 with 'zypper dup', my other systems without this problem are fresh installed with recycled $HOME, the PID of akonadi* are higher then of dbus-daemon

so it looks for me, that something in the KDE-Start is wrong, it must be changed between openSUSE 12.3 and 13.1

sorry for my bad english, i'm willing to answer Mails in german

Bernd
Comment 38 Jörg Schuck 2013-12-19 10:22:49 UTC
@Bernd: Can't confirm that theory, unfortunately. The problem is occuring on  my systems at random. I look at my Arch box and dbus-daemon has the PID 837 while akonadi_control has 1059 and akonadiserver1061 and still it fails to start any agents at random. 

And i still have a mysqlcheck zombie process lurking about. So far only the manual shutting down and restarting fixes it.
Comment 39 Bernd Weigelt 2013-12-19 10:32:21 UTC
@Jörg: possible two different problems?

I just made a reboot after some updates from opensuse, akonadi has started successful
the akonadi-*-PID (4759) are higher then dbus (4614)
my akonadi-starts are fifty-fifty successful in the last days, so i can't find a solution for me
:(
Comment 40 Bernd Weigelt 2013-12-19 10:33:15 UTC
@Jörg: i have no mysql zombies
Comment 41 szymon.pysz@gmail.com 2013-12-19 10:36:00 UTC
Hi all!

Recently I updated KDE to version 4.11.4 (Gentoo Linux). So far, every time akonadi start without any problem. 
I also check PID. The Akonadi PID is higer than dbus.  

Very odd issue.

Regards,
Simon
Comment 42 Jörg Schuck 2013-12-19 10:40:06 UTC
@Bernd: Interesting. My rate is about 50/50 as well. But i noticed it working everytime after a reboot but not always after a cold boot.
@Simon: Mmh. Well 4.12 should be hitting my repos pretty soon. Let's see if that changes anything.
Comment 43 Bernd Weigelt 2013-12-19 10:47:47 UTC
@Jörg: 
yes,  most(all) starts after reboot are successful, after cold boot not
Comment 44 Andreas Roth 2013-12-19 10:51:31 UTC
i've two system with the latest 4.12 installed. on one machine (at work) the problem occurs on every system start and on the second machine (at home) the problem does not occur at all.
Comment 45 T Kleindienst 2013-12-20 09:27:35 UTC
I'm running 4.11.3 on opensuse 13.1. After running kontact about 2-3 times, it refuses to start. 

Test 10:  ERROR Akonadi control process not registered at D-Bus.
Test 11:  ERROR Akonadi server process not registered at D-Bus.

I did a fresh install of suse 13.1 yesterday. I also started with a fresh end empty ~!
I'm only using imap resources.

On suse 12.3 Akonadi/Kontact was working nicely.
Comment 46 Bernd Weigelt 2013-12-20 09:50:33 UTC
after update to KDE 4.12.0 same problem, but ideas about the PIDs are completely useless
so please ignore them
It doesn't matter whether, if the PIDs are higher or lower
Comment 47 bspire 2013-12-20 14:23:44 UTC
I can confirm this bug on Arch Linux with KDE 4.11.4.

Killing akonadi_control, akonadiserver and mysqld processes and restarting akonadi afterwards let akonadi run fine until the next reboot :)
Comment 48 jajaX 2013-12-20 22:03:54 UTC
Hi all !!

same problem after 13.10 upgrade (from 13.04). update 4.12 not solved it.
Comment 49 jacob.greenstein 2013-12-20 23:03:01 UTC
I have the same problem on Fedora 20 (KDE 4.11.4), and had it on Fedora 19 for about a month. The only way to get akonadi work again is to remove all its config files, kill all akonadi-related processes and restart it.
Comment 50 Graeme Hewson 2013-12-20 23:32:49 UTC
I'm not using Fedora, but I haven't found it necessary to remove Akonadi's config files to get it working.
Comment 51 Hussam Al-Tayeb 2013-12-21 07:30:52 UTC
In case it helps, I am using Qt 4.8.5 and dbus 1.6.18
Comment 53 Jörg Schuck 2013-12-21 12:23:23 UTC
Ok. I at least have a nvidia card in my system and the 331.20 driver installed.
Comment 54 Bernd Weigelt 2013-12-21 12:27:50 UTC
ok, also a nvidia card with manually installed 331.20 driver
Comment 55 Tsu Jan 2013-12-21 12:41:15 UTC
I also have nvidia 331-20, installed from Debian Experimental.
Comment 56 Graeme Hewson 2013-12-21 13:01:06 UTC
Nvidia 319.60 here!
Comment 57 Christian (Fuchs) 2013-12-21 13:11:27 UTC
For all of those who now commented with "yes, nvidia here!" and similar: it would probably be more helpful both for you and others if you actually did downgrade to the version I mentioned and see if the problem persists. 

If not: you got rid of the problem, people know what the cause is and they know a workaround until nvidia releases a new driver. 

Kind regards, 

Fuchs
Comment 58 Tsu Jan 2013-12-21 13:24:03 UTC
I downgraded to 325.15 and Akonadi started OK after two reboots and a logout-login. I'll tell you if the problem still happens with this driver. It'll take some time to be sure.

BTW, nvidia-319.X may have bugs (https://devtalk.nvidia.com/default/topic/638521/linux/gnome-terminal-problems-ctrl-c-and-exit/).
Comment 59 Tsu Jan 2013-12-22 10:25:51 UTC
With nvidia-325.15, I've had several reboots, cold boots and log-ins, and Akonadi started well every time.

BTW, most of the random problems I mentioned in Comment 25 were caused by nvidia-331.20 too. Even Amarok didn't exit on quitting sometimes. Thank you, Fuchs!
Comment 60 Graeme Hewson 2013-12-22 12:56:21 UTC
I removed my nVidia card and the driver, and Akonadi starts OK now.

I didn't experience the problems in the other reports in comment 52 of ^C not working in xterm (or Konsole, either).

I have a suspicion that I was mistaken in comment 32 when I said that Akonadi only started 4 out of 5 times after renaming /usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service. Testing now, I found I wasn't always allowing enough time, so "akonadictl status" might say "stopped", but a moment later it would say "running".
Comment 61 T Kleindienst 2013-12-22 14:46:55 UTC
.
.
I removed all proprietary Nvidia stuff and switched to using Nouveau drivers.
Akonadi starts o.k.. No problems whatsoever so far. 
Seems the current Nvidia drivers were causing the troubles.
Still I need the proprietary drivers for my CAD stuff. Maybe using Nvidia 325.15 is an "interim" option...
Comment 62 Jörg Schuck 2013-12-22 20:56:56 UTC
No problems after the nvidia driver downgrade so far. Akonadi started consistently the last days.
Comment 63 neutrino 2013-12-23 00:36:54 UTC
WTF is this bug? every month I can't use kontact because something is broken (akonadi, kmail, nepomuk, ...) and now it is the Nvidia driver? I have upgraded the nvidia driver to 331.20-3 on archlinux and upgraded to the newes kernel 3.12.6-1 after reboot akonadi seems to work now...
Comment 64 Tsu Jan 2013-12-23 08:37:10 UTC
@neutrino
As you see, many users have confirmed that it's an nVidia bug, and it affects other apps too. So, the Akonadi devs can do nothing about it.
Comment 65 Falk 2013-12-23 10:14:02 UTC
I just wanted to point out, I'm affected by this bug and I'm not using the broken 331.20 nividia driver, I'm still on 319.60. This driver was working fine with KDE 4.10 and also akonadi was ok for me with KDE 4.10 and now I'm on KDE 4.11 and I'm encountering the problem.

I have also no problems of other programs not starting, only akonadi needs a kick after a reboot of the system and on my system I can see akonadi processes running, they are just not responding properly.

So there are actually two problems in this bug here. 
* One with the broken nvidia driver where the akonadi devs can't do anything
* And the one that some others here and I'm facing where akonadi fails to register/respond properly at the dbus where I think the akonadi devs can do something, because this looks like a racing condition in the startup phase.
Comment 66 Dimitrios Glentadakis 2013-12-23 10:47:38 UTC
I downgraded to 319.60 and i can still reproduce it
I could n't reproduce it with nouveau (tested 1 time)

I have this configuration:

dkms-nvidia-current-319.60-1.mga3.nonfree
nvidia-current-doc-html-319.60-1.mga3.nonfree
nvidia-current-kernel-3.10.24-desktop-2.mga3-319.60-8.mga3.nonfree
nvidia-current-kernel-3.10.25-desktop-1.mga3-319.60-9.mga3.nonfree
nvidia-current-kernel-desktop-latest-319.60-9.mga3.nonfree
x11-driver-video-nvidia-current-319.60-1.mga3.nonfree
[dglent@localhost ~]$ uname -r
3.10.25-desktop-1.mga3
[dglent@localhost ~]$
Comment 67 Christian (Fuchs) 2013-12-23 11:29:33 UTC
Hi again, 

as mentioned in the reports linked, there are lots of different drivers affected, not only 331.20.  So people experiencing this should down- / update to the also mentioned 325.15, as that is the only halfway recent driver that is known to work. If the problem still persists, then it's a different bug. Else it's quite probably this one, as it got confirmed not only by lots of users on different distributions but also by nvidia.

Kind regards, 

Fuchs
Comment 68 Hussam Al-Tayeb 2013-12-24 19:21:50 UTC
331.20 was released on november 6 so it's probably not too long till we see a new driver.
Comment 69 Jens Westemeier 2013-12-27 10:54:49 UTC
Here some more data points:
I got the problem when migrating from OpenSuSE 12.3 to 13.1. I upgraded KDE from 4.11.4 to 4.12.0, the problem remained.
I have installed Nvidia nvidia-gfxG03-kmp-desktop-331.20_k3.11.6_4-22.2.x86_64, nvidia-computeG03-331.20-22.1.x86_64 and x11-video-nvidiaG03-331.20-22.1.x86_64 from the OpenSuSE Build Service.
But:
I can run K-Mail (including the implicit start of akonadi) immediately (<10s) after having started the system and logged into my KDE session. Later than that akonadi does not start. So it might be a raise condition with other services.
Comment 70 Daniel Vrátil 2014-01-02 13:35:20 UTC
Thanks everyone for the input and for confirming this is caused by the nvidia driver.

Those who still experience the bug with nvidia-319.xx (which reportedly should work) could you please try nouveau to make sure it's not yet another issue in the binary drivers? If you can reproduce the problem with nouveau, please open a new bug report. We will use this one to track only the nvidia-related issue.

I'll close this as UPSTREAM, since we can't do anything about it. As recommended in comments above, either wait for nvidia to release an update, downgrade to nvdia-319.xx or switch to the open source nouveau driver.
Comment 71 Christian (Fuchs) 2014-01-02 13:37:33 UTC
(In reply to comment #70)
> Thanks everyone for the input and for confirming this is caused by the
> nvidia driver.
> 
> Those who still experience the bug with nvidia-319.xx (which reportedly
> should work) 

Minor sidenote, I'd recommend  325.15 which works according to several bug reports and on my system here, and probably supports a bit more hardware. 

Kind regards, 

Christian
Comment 72 T Kleindienst 2014-01-13 17:18:45 UTC
Nvidia released their binary driver version 331.38 on Jan 13th. Did anybody check it already?
(last time I checked was with 331.20 which was giving troubles)
Comment 73 T Kleindienst 2014-01-13 17:57:22 UTC
(In reply to comment #72)

Just checked it myself. No Suse packages yet. I used the binary installation file from Nvidia. So far it seems to work. Akonadi is up and running...
Comment 74 Hussam Al-Tayeb 2014-01-13 21:09:20 UTC
does it still happen with this driver?
http://us.download.nvidia.com/XFree86/Linux-x86_64/331.38/NVIDIA-Linux-x86_64-331.38-no-compat32.run
Comment 75 jacob.greenstein 2014-01-14 06:13:39 UTC
I installed it about an hour ago (needless to say, there is no package for Fedora yet). Akonadi started seamlessly after a reboot.
Comment 76 Hussam Al-Tayeb 2014-01-14 06:17:46 UTC
I updated to new driver from archlinux repository and i tried everything from logging off/logging back on and rebooting. no akonadi failures so far.
Comment 77 Mark Fraser 2014-01-17 08:02:23 UTC
Kubuntu 13.10 with KDE 4.12, just added the xorg-edgers PPA and updated to 331.38 and Akonadi is still not starting.
Comment 78 Bernd Weigelt 2014-01-17 08:36:35 UTC
openSUSE 13.1 with KDE 4.12.1 and Nvidia 331.38 
driver installed 3 days ago and akonadi starts without any problem

my problem is fixed 

thx
Bernd
Comment 79 Mark Fraser 2014-01-17 19:46:31 UTC
Kubuntu 13.10 with KDE 4.12, just added the xorg-edgers PPA and updated to 331.38 and Akonadi is still not starting.
Comment 80 eli 2014-01-22 14:53:26 UTC
Confirmed the fix on Fedora 20. As indicated no rpms yet.
Comment 81 Tsu Jan 2014-01-22 15:07:24 UTC
I also confirm that the issue is fixed, on Debian and with nVidia 331.38 from its Experimental repository.
Comment 82 Jekyll Wu 2014-01-28 08:28:16 UTC
*** Bug 327411 has been marked as a duplicate of this bug. ***