Since this isn't seems to be a distro-specific problem but rather something with KDE configuration itself, I copy & paste here my post in the hope that a KDE guru may know what's happening and be able to help me :)

I'm currently running KDE SC 4.9 on Arch Linux x86_64, system fully up to date.

Ok, I know a lot of you cynics would say: "it's fine, why would do you want Nepomuk running anyways!?"

The truth is my laptop HD went dead some days ago so I had to restore my system from a 2-weeks old backup; I usually use fsarchiver to backup root partition and 7z to compress ~/.kde4 so this way I'm covered up about these kind of things.
So after restoring my system and home folder I did a full upgrade (nearly a gigabyte of downloads) and while most things seems to work well I found that Nepomuk isn't running, when I try to start it manually I have this error message:

"Failed to start the desktop search service (Nepomuk). The settings have been saved and will be used the next time the server is started."

Going back to the wiki I did my homework re-configuring Akonadi but so far I can't make Nepomuk run.
This is what I have:

~/.config/akonadi/akonadiserverrc
[%General]
Driver=QMYSQL

[QMYSQL]
Name=akonadi
Host=localhost
ServerPath=/usr/bin/mysqld
StartServer=true
User=akonadiuser
Password=akonadiuser
Options="UNIX_SOCKET=/home/msx/.local/share/akonadi/socket-heybeavis/mysql.socket"

[Debug]
Tracer=null


The database is already created and configured:
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| akonadi
| mysql
| owncloud
| performance_schema |
+--------------------+
5 rows in set (0.00 sec)


and the ~/.config/akonadi/mysql-local.conf is in place:
~ $ cat ~/.config/akonadi/mysql-local.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


Now, when I do restart Akonadi server I got:
~ $ akonadictl restart
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
search paths: ("/usr/local/bin", "/usr/bin", "/bin", "/usr/local/sbin", "/usr/sbin", "/sbin", "/usr/bin/vendor_perl", "/usr/bin/core_perl", "/usr/bin/msx", "/usr/lib/colorgcc/bin", "/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
Nepomuk Query Server not available
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
search paths: ("/usr/local/bin", "/usr/bin", "/bin", "/usr/local/sbin", "/usr/sbin", "/sbin", "/usr/bin/vendor_perl", "/usr/bin/core_perl", "/usr/bin/msx", "/usr/lib/colorgcc/bin")
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work
"/usr/bin/akonadi_nepomuk_feeder(13892)" Soprano: "Could not connect to server at /tmp/ksocket-msx/nepomuk-socket (No such file or directory)"
"/usr/bin/akonadi_nepomuk_feeder(13892)" Soprano: "Could not connect to server at /tmp/ksocket-msx/nepomuk-socket (No such file or directory)"
"/usr/bin/akonadi_nepomuk_feeder(13892)" Soprano: "Could not connect to server at /tmp/ksocket-msx/nepomuk-socket (No such file or directory)"
"/usr/bin/akonadi_nepomuk_feeder(13892)" Soprano: "Could not connect to server at /tmp/ksocket-msx/nepomuk-socket (No such file or directory)"
search paths: ("/home/msx/.kde4/lib/kde4/plugins/", "/usr/lib/kde4/plugins/", "/home/msx/.kde4/lib/kde4/plugins/", "/usr/lib/kde4/plugins/", "/usr/lib/qt/plugins", "/usr/bin", "/usr/lib/kde4/plugins", "/home/msx/.kde4/lib/kde4/", "/usr/lib/kde4/")
AkonadiAgentServer(13913)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
AkonadiAgentServer(13913)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:



Please correct me if I'm wrong but seems Akonadi can't/don't create the resource needed by Nepomuk, right?
"/usr/bin/akonadi_nepomuk_feeder(13892)" Soprano: "Could not connect to server at /tmp/ksocket-msx/nepomuk-socket (No such file or directory)"

Already raked the forums and the net but can't find anything of help :(
Regards,
Martin

Further research shows up Akonadi may be not connecting to MySQLd by socket, any idea why?


* UPDATE *
Indeed was actually a local problem, solved by reinstalling full MySQL stack, thanks.

Are you still having issues with Nepomuk?
If so, can you check to see if nepomukserver is running?

bcooksley wrote:Are you still having issues with Nepomuk?
If so, can you check to see if nepomukserver is running?

Nope, as I previously posted it was my fault and now it's solved, seems like it was a broken MySQL installation after a system recovery.

Marked as Solved.