Page 3 of 9 FirstFirst 12345 ... LastLast
Results 21 to 30 of 82

Thread: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

  1. #21

    Default Re: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Quote Originally Posted by jaybarkei View Post
    - akonadi_search is not on my system, just akonadi-search from akonadi5, and there never was a problem.
    That is what I meant. Try to remove it.

    - I tried to move the akonadi/kontact bunch back to the standard repos, but that didn't change a thing. Moving completely back to standard repos would be the last resort, but I don't want to do it just now.
    The standard repos have exactly the same KDEPIM5 and Akonadi packages since today.
    And if the problem is indeed Qt 5.6.0, switching KDEPIM5 and Akonadi won't help at all.
    Actually it should help to only switch Qt5 then, but that would also require a downgrade of Plasma5.

    - akonadictl stop leads directly to new prompt, akonadictl start thereafter leads to "Akonadi is already running", so it seems, like it hangs somehow.
    Yes, and that would also explain why the applications cannot connect to it.

    But just to be sure: it is normal that there's no output when running "akonadictl stop", and it can take a while until all processes are quit and Akonadi has shutdown completely. So wait a bit until trying to run "akonadictl start".

    - then:
    Code:
    qdbus org.freedesktop.Akonadi /notifications subscribers
    qdbus: I don't know how to display an argument of type 'ao', run with --literal.
    
    
    Ok, then add the "--literal" as suggested:
    Code:
    qdbus --literal org.freedesktop.Akonadi /notifications subscribers
    I used the KDE4 version when posting, where it worked without.

    - I also tried to start kontact from konsole tih the following output (which stopped after the last line), took a while till the program started, I stopeed it then with ctl-c. Maybe this hints somewhere.
    I don't see anything wrong there. (you can ignore those "errors" from Akregator that it "Couldn't reach favicon service.", that's definitely unrelated to your problem...)

    But it would rather suggest that Akonadi is working fine and not hanging.

  2. #22

    Default AW: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Okay ...

    I added the --literal option and had this response:

    Code:
    qdbus --literal org.freedesktop.Akonadi /notifications subscribers
    [Argument: ao {[ObjectPath: /subscriber/akonadi_maildir_resource_0_14858_NWstXH], [ObjectPath: /subscriber/akonadi_akonotes_resource_3_14840_ubxbU6], [ObjectPath: /subscriber/akonad
    i_newmailnotifier_agent_14871_OzS6tx], [ObjectPath: /subscriber/akonadi_pop3_resource_8_14897_FdBRIJ], [ObjectPath: /subscriber/akonadi_ical_resource_0_14854_owM8Ga], [ObjectPath: /
    subscriber/akonadi_akonotes_resource_0_14837_3gZ77j], [ObjectPath: /subscriber/akonadi_migration_agent_14870_72j9Wh], [ObjectPath: /subscriber/akonadi_pop3_resource_4_14890_OPQoeO],
     [ObjectPath: /subscriber/akonadi_maildispatcher_agent_14864_Mhpce5], [ObjectPath: /subscriber/akonadi_pop3_resource_7_14893_2Px1ia], [ObjectPath: /subscriber/akonadi_notes_agent_14
    872_RenOgq], [ObjectPath: /subscriber/akonadi_pop3_resource_5_14891_muRUCC], [ObjectPath: /subscriber/akonadi_akonotes_resource_2_14839_mOsQuM], [ObjectPath: /subscriber/akonadi_arc
    hivemail_agent_14842_Jlc4xU], [ObjectPath: /subscriber/akonadi_followupreminder_agent_14852_UY291M], [ObjectPath: /subscriber/akonadi_sendlater_agent_14900_EDVNOk], [ObjectPath: /su
    bscriber/akonadi_pop3_resource_2_14880_E0LmLv], [ObjectPath: /subscriber/akonadi_notes_agent_14872_1tB6TU], [ObjectPath: /subscriber/akonadi_archivemail_agent_14842_p90NkD], [Object
    Path: /subscriber/akonadi_maildispatcher_agent_14864_O1lOrX], [ObjectPath: /subscriber/akonadi_pop3_resource_6_14892_N5Qnl7], [ObjectPath: /subscriber/akonadi_birthdays_resource_148
    43_zsofyW], [ObjectPath: /subscriber/akonadi_maildispatcher_agent_14864_9Cdgnt], [ObjectPath: /subscriber/akonadi_contacts_resource_0_14846_kYpkHu], [ObjectPath: /subscriber/akonadi
    _maildir_resource_1_14863_Ke2xbf], [ObjectPath: /subscriber/akonadi_akonotes_resource_1_14838_SCApEp], [ObjectPath: /subscriber/akonadi_akonotes_resource_4_14841_fJGgQo], [ObjectPat
    h: /subscriber/akonadi_davgroupware_resource_1_14847_VYViWA], [ObjectPath: /subscriber/akonadi_pop3_resource_1_14874_MdihYZ], [ObjectPath: /subscriber/akonadi_birthdays_resource_148
    43_4kBbGY], [ObjectPath: /subscriber/akonadi_pop3_resource_3_14885_RpR8qb], [ObjectPath: /subscriber/akonadi_archivemail_agent_14842_O9wOUp], [ObjectPath: /subscriber/akonadi_pop3_r
    esource_0_14873_iiCFsm]}]
    
    
    - Tried again akonadictl stop and waited about 5 min until akonadictl start: same result. BUT: akonadi and subthreads have been doing something: where there was cputime 0:00 in ksysguard before, now is between 0.01 and 0.04 ... don't know what that could mean ...

  3. #23

    Default Re: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Quote Originally Posted by bearymore View Post
    I had the experience with logging in and out, but it did not involve any changed/upgraded packages. My experience was - reboot and the problem manifested itself. Log out of KDE, log back in and the problem was "fixed". Reboot and the problem reappeared and was fixed again by the log out/log in procedure. No package changes were involved. Something was running in the bootup session (which remained in the process list after the logout/login procedure) that was not running in the newly logged in session. Could mixed packages cause the system to boot up with Akonadi4 and then switch in a new session to Akonadi5?

    At any rate, the problem is fixed and did have something to do with mixed packages as Wolfi suggested. His presence in these forums has been a life saver for me and I really appreciate it.
    I spoke too soon. The problem is back with a reboot today. There are no mixed packages and I am running akonadi 5.1.51. The problem recurs on reboot again and is cured by the logout / login "fix" leaving a stopped plasmashell and a previous running version of akonadictl both of which can be killed with no affect on the running plasmashell. There was an update of the KDE apps today both in the normal updated repository and in the Applications repository. I made sure all my updates came from the applications repository so, again, mixed packages not a problem.

  4. #24

    Default Re: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    For the record, I did switch my Leap VM to KDEPIM5/Akonadi5 and Qt 5.6.0 (using KDE:Qt5, KDE:Frameworks5, and KDE:Applications) yesterday, and still everything is working fine.
    I did get an "Akonadi self test error" dialog on first start of Kontact, but that's rather "normal" and I have seen this in KDE4 already as well. It's because Akonadi takes longer to start (as it creates the database and default resources) which can cause a timeout. After closing that dialog (and Akonadi was fully running), it worked fine though.

    So at least there's no general problem (like e.g. an incompatibility with Qt 5.6.0).

    Unfortunately I have no idea at the moment what else to try or investigate.
    As it works fine for bearymore after logout/login, it might be some timing problem, as already mentioned.
    I'd suggest to make sure that Akonadi (and KDEPIM applications) are not started at login, but only start them manually afterwards, when the desktop has settled down.

    The output posted by jaybarkei would actually suggest that everything is working like it should...
    Maybe there's a password/kwallet dialog somewhere in the background, or kwallet is hanging? Maybe try to disable kwallet as a test (in systemsettings5, or kwalletmanager5). That's another reason for hanging I could imagine.

    But apparently you both have problems with Akonadi not reacting, and not stopping too.

    I remember similar problems (with Akonadi4 and other KDE4 applications) being caused by a bug in the nvidia driver some time ago. I am not aware of such a problem currently, but as I'm running out of ideas anyway... Are you both maybe using the nvida driver?

    Other than that, I'm afraid we can only wait for 16.04 (to be released in 2 weeks, the RC will be available on Wednesday but I'm not sure if the packages will be published...) and hope that it fixes your probems.

  5. #25

    Default Re: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Thanks for the response Wolfi. I'm actually using the FGLRX driver.

  6. #26

    Default Re: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't wo

    Quote Originally Posted by bearymore View Post
    Thanks for the response Wolfi. I'm actually using the FGLRX driver.
    Yeah, I didn't really believe that this is the problem.
    I just mentioned it in lack of other ideas...

    One other thing though: I do experience from time to time in KMail that certain Akonadi resources are getting stuck and prevent others from working correctly (or responding at all) too.
    But that's the case in KDE4/Akonadi4 too. It actually has improved in the KF5 version, though not fixed completely.
    Killing the offending resource always helps here, it is one particular IMAP resource with one particular IMAP server in my case (i.e. I don't see that problem with other accounts).

    This only affects KMail though AFAICT, and it doesn't cause the exact same problem as mentioned here, so might not even be remotely related to the problems you two have.

    Still, when Akonadi is stuck, maybe try to kill Akonadi resources (akonadi_xxx_resource) one by one with Plasma's system monitor (Ctrl+ESC).
    They should get restarted automatically.
    If that helps, it would even narrow down the problem (and help nailing it down...).

    Just another guess though.
    Last edited by wolfi323; 06-Apr-2016 at 13:18.

  7. #27

    Default Re: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Thanks, Wolfi. Next time I reboot, I'll try killing resources and see what happens.

  8. #28

    Default AW: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Sorry Guys,

    but I have to return to this subject again, because with the installation of KDE Apps 16.04 things have NOT changed. Kontact and akonadiconsole still report Akonadi as "not working properly" and in my view I have to make some decisions, becuase things can't stay the way they are. I need a working email, address book and Organizer solution and can't wait till someone found out what is really going wrong here.

    So the question for me is: Am I dealing with a software bug here, or does it look more like a mere config related problem?

    If it is the latter, I would rather restart from zero by eliminating all relevant config data and let akonadi create a new config. In a way I have to change my config anyway since I have a mail server running on my NAS since a few days and would like to collect all my Emails there, as well as my contacts and calendar data.

    The question then is: which part of the akonadi and kontact configuration do I have have to and may safely erase, while preserving my emails (which are in a seperate dir), since - unfortunately - not all backups of them are really current (most are, but since akonadi was broken quite surprisingly, I had no chance to do backups manually. Interestingly, the kmail backup-assistant worked even after akonadi broke, so I'm hopefull that there might be a chance even for the Mails that I had not included into my frequent backups (which I am going to change now)).

    But I was able to get some new information on the subject, by creating an akonadi selftest report a few days ago (when V.16.04 was NOT installed (and please don't ask me, how to do it again)), and I started akonadiconsole today AFTER installing V.16.04, and got some of the feedback in konsole. Maybe this helps nailing down the problem.
    Here's what I did (after installing KDE Apps 16.04):


    1. starting kontact ==> "not working properly"
    2. starting akonadiconsole ==> same result, stopping/killing akonadiconsole
    3. killing all akonadi-related processes and all kontact processes
    4. starting akonadiconsole again, feddback can be found in Code -Example 3


    So here is what I have (And the forum system forced me to split this post, so you find the data in seperate posts since adding files is not possible)

    LOOK following Posts!


    Okay, I hope these things do help finding the reason for the problem, whether it is a bug or some config error (which I have afais not produced myself), but mor important for me is, how to restart from scratch without losing all of my mails.

    Thanks a lot for now.

    Jay

  9. #29

    Default AW: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    1. Akonadi selftest report fro 13.04.2016 (Opensuse Leap 42.1, current, KDE 5.21, Plasma 5.6.2, KDE Apps 5.12.3) in next post
    Code:
    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/jmbarkei/.config/akonadi/akonadiserverrc':
    [Debug]
    Tracer=null
    
    [%General]
    Driver=QMYSQL
    
    [QMYSQL]
    Host=
    Name=akonadi
    Options="UNIX_SOCKET=/tmp/akonadi-jmbarkei.8CV1R5/mysql.socket"
    ServerPath=/usr/sbin/mysqld
    StartServer=true
    
    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: 160413 14:52:48 [Note] /usr/sbin/mysqld (mysqld 10.0.22-MariaDB) starting as process 6633 ...
    /usr/sbin/mysqld  Ver 10.0.22-MariaDB for Linux on x86_64 (openSUSE package)
    
    Test 5:  WARNING
    --------
    
    MySQL server log contains warnings.
    Details: The MySQL server log file '<a href="/home/jmbarkei/.local/share/akonadi/db_data/mysql.err">/home/jmbarkei/.local/share/akonadi/db_data/mysql.err</a>' contains warnings.
    
    File content of '/home/jmbarkei/.local/share/akonadi/db_data/mysql.err':
    160413 14:46:53 [Note] InnoDB: Using mutexes to ref count buffer pool pages
    160413 14:46:53 [Note] InnoDB: The InnoDB memory heap is disabled
    160413 14:46:53 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    160413 14:46:53 [Note] InnoDB: Memory barrier is not used
    160413 14:46:53 [Note] InnoDB: Compressed tables use zlib 1.2.8
    160413 14:46:53 [Note] InnoDB: Using Linux native AIO
    160413 14:46:53 [Note] InnoDB: Using CPU crc32 instructions
    160413 14:46:53 [Note] InnoDB: Initializing buffer pool, size = 80.0M
    160413 14:46:53 [Note] InnoDB: Completed initialization of buffer pool
    160413 14:46:53 [Note] InnoDB: Setting log file ./ib_logfile101 size to 64 MB
    160413 14:46:54 [Note] InnoDB: Setting log file ./ib_logfile1 size to 64 MB
    160413 14:46:56 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
    160413 14:46:56 [Warning] InnoDB: New log files created, LSN=16172788833
    160413 14:46:56 [Note] InnoDB: Highest supported file format is Barracuda.
    160413 14:46:56 [Note] InnoDB: 128 rollback segment(s) are active.
    160413 14:46:56 [Note] InnoDB: Waiting for purge to start
    160413 14:46:57 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence number 16172789260
    160413 14:46:57 [Note] Reading of all Master_info entries succeded
    160413 14:46:57 [Note] Added new Master_info '' to hash table
    160413 14:46:57 [Note] /usr/sbin/mysqld: ready for connections.
    Version: '10.0.22-MariaDB'  socket: '/tmp/akonadi-jmbarkei.8CV1R5/mysql.socket'  port: 0  openSUSE package
    160413 14:51:58 [Note] /usr/sbin/mysqld: Normal shutdown
    
    160413 14:51:58 [Note] InnoDB: FTS optimize thread exiting.
    160413 14:51:58 [Note] InnoDB: Starting shutdown...
    160413 14:52:00 [Note] InnoDB: Shutdown completed; log sequence number 16172789280
    160413 14:52:00 [Note] /usr/sbin/mysqld: Shutdown complete
    
    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/xdg/akonadi/mysql-global.conf">/etc/xdg/akonadi/mysql-global.conf</a>.
    
    File content of '/etc/xdg/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:8M)
    # Deprecated in MySQL >= 5.6.3, removed in 5.7 (works in MariaDB)
    # innodb_additional_mem_pool_size=8M
    
    # 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_open_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
    
    # We use InnoDB, so don't let MyISAM eat up memory
    key_buffer_size=16K
    
    [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/jmbarkei/.local/share/akonadi/mysql.conf">/home/jmbarkei/.local/share/akonadi/mysql.conf</a> and is readable.
    
    File content of '/home/jmbarkei/.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:8M)
    # Deprecated in MySQL >= 5.6.3, removed in 5.7 (works in MariaDB)
    # innodb_additional_mem_pool_size=8M
    
    # 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_open_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
    
    # We use InnoDB, so don't let MyISAM eat up memory
    key_buffer_size=16K
    
    [client]
    default-character-set=utf8
    TEST 9 and following in the following post!!

  10. #30

    Default AW: After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

    Rest of "Akonadi selftest !!

    Code:
    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 5.1.90
    
    Test 10:  SUCCESS
    --------
    
    Akonadi control process registered at D-Bus.
    Details: The Akonadi control process is registered at D-Bus which typically indicates it is operational.
    
    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:  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 13:  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'; make sure this includes all paths where Akonadi agents are installed.
    
    Directory listing of '/usr/share/akonadi/agents':
    akonadiindexingagent.desktop
    akonotesresource.desktop
    archivemailagent.desktop
    birthdaysresource.desktop
    contactsresource.desktop
    davgroupwareresource.desktop
    followupreminder.desktop
    googlecalendarresource.desktop
    googlecontactsresource.desktop
    icaldirresource.desktop
    icalresource.desktop
    imapresource.desktop
    invitationsagent.desktop
    kalarmdirresource.desktop
    kalarmresource.desktop
    knutresource.desktop
    kolabresource.desktop
    maildirresource.desktop
    maildispatcheragent.desktop
    mailfilteragent.desktop
    mboxresource.desktop
    migrationagent.desktop
    mixedmaildirresource.desktop
    newmailnotifieragent.desktop
    notesagent.desktop
    notesresource.desktop
    openxchangeresource.desktop
    pop3resource.desktop
    sendlateragent.desktop
    vcarddirresource.desktop
    vcardresource.desktop
    
    Environment variable XDG_DATA_DIRS is set to '/usr/share'
    
    Test 14:  ERROR
    --------
    
    Current Akonadi server error log found.
    Details: The Akonadi server reported errors during its current startup. The log can be found in <a href="/home/jmbarkei/.local/share/akonadi/akonadiserver.error">/home/jmbarkei/.local/share/akonadi/akonadiserver.error</a>.
    
    File content of '/home/jmbarkei/.local/share/akonadi/akonadiserver.error':
    "Cannot connect to agent instance with identifier 'akonadi_akonotes_resource_1', error message: ''" 
    "Cannot connect to agent instance with identifier 'akonadi_akonotes_resource_1', error message: ''" 
    
    Test 15:  ERROR
    --------
    Previous Akonadi server error log found.
    Details: The Akonadi server reported errors during its previous startup. The log can be found in <a href="/home/jmbarkei/.local/share/akonadi/akonadiserver.error.old">/home/jmbarkei/.local/share/akonadi/akonadiserver.error.old</a>.
    
    File content of '/home/jmbarkei/.local/share/akonadi/akonadiserver.error.old':
    Control process died, committing suicide! 
    
    Test 16:  ERROR
    --------
    
    Current Akonadi control error log found.
    Details: The Akonadi control process reported errors during its current startup. The log can be found in <a href="/home/jmbarkei/.local/share/akonadi/akonadi_control.error">/home/jmbarkei/.local/share/akonadi/akonadi_control.error</a>.
    
    File content of '/home/jmbarkei/.local/share/akonadi/akonadi_control.error':
    "[\n0: /usr/bin/akonadi_control() [0x427a73]\n1: /usr/bin/akonadi_control() [0x427d59]\n2: /lib64/libc.so.6(+0x35120) [0x7f03c1d7d120]\n3: /lib64/libdbus-1.so.3(+0x1eb2e) [0x7f03c1902b2e]\n4: /lib64/libdbus-1.so.3(+0x17bc2) [0x7f03c18fbbc2]\n5: /lib64/libdbus-1.so.3(dbus_message_unref+0xc2) [0x7f03c18fc0d2]\n6: /usr/lib64/libQt5DBus.so.5(+0x2ee97) [0x7f03c34c7e97]\n7: /usr/lib64/libQt5DBus.so.5(_ZN12QDBusMessageD1Ev+0x1b) [0x7f03c34c806b]\n8: /usr/lib64/libQt5DBus.so.5(+0x2173c) [0x7f03c34ba73c]\n9: /usr/lib64/libQt5DBus.so.5(+0x217a9) [0x7f03c34ba7a9]\n10: /usr/lib64/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x1d3) [0x7f03c28fadf3]\n11: /usr/lib64/libQt5Core.so.5(+0x2c0d53) [0x7f03c2949d53]\n12: /usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x254) [0x7f03bfde7c84]\n13: /usr/lib64/libglib-2.0.so.0(+0x4bed8) [0x7f03bfde7ed8]\n14: /usr/lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f03bfde7f7c]\n15: /usr/lib64/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5c) [0x7f03c29493dc]\n16: /usr/lib64/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0xfb) [0x7f03c28f704b]\n17: /usr/lib64/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x86) [0x7f03c28fef56]\n18: /usr/bin/akonadi_control() [0x4097eb]\n19: /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f03c1d69b05]\n20: /usr/bin/akonadi_control() [0x4099e7]\n]\n" 
    ProcessControl: Application /usr/bin/akonadi_akonotes_resource stopped unexpectedly ( "Process crashed" ) 
    
    Test 17:  SUCCESS
    --------
    
    No previous Akonadi control error log found.
    Details: The Akonadi control process did not report any errors during its previous startup.
    2. Corresponding Mysql.err
    Code:
    160413 14:46:53 [Note] InnoDB: Using mutexes to ref count buffer pool pages160413 14:46:53 [Note] InnoDB: The InnoDB memory heap is disabled
    160413 14:46:53 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    160413 14:46:53 [Note] InnoDB: Memory barrier is not used
    160413 14:46:53 [Note] InnoDB: Compressed tables use zlib 1.2.8
    160413 14:46:53 [Note] InnoDB: Using Linux native AIO
    160413 14:46:53 [Note] InnoDB: Using CPU crc32 instructions
    160413 14:46:53 [Note] InnoDB: Initializing buffer pool, size = 80.0M
    160413 14:46:53 [Note] InnoDB: Completed initialization of buffer pool
    160413 14:46:53 [Note] InnoDB: Setting log file ./ib_logfile101 size to 64 MB
    160413 14:46:54 [Note] InnoDB: Setting log file ./ib_logfile1 size to 64 MB
    160413 14:46:56 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
    160413 14:46:56 [Warning] InnoDB: New log files created, LSN=16172788833
    160413 14:46:56 [Note] InnoDB: Highest supported file format is Barracuda.
    160413 14:46:56 [Note] InnoDB: 128 rollback segment(s) are active.
    160413 14:46:56 [Note] InnoDB: Waiting for purge to start
    160413 14:46:57 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence number 16172789260
    160413 14:46:57 [Note] Reading of all Master_info entries succeded
    160413 14:46:57 [Note] Added new Master_info '' to hash table
    160413 14:46:57 [Note] /usr/sbin/mysqld: ready for connections.
    Version: '10.0.22-MariaDB'  socket: '/tmp/akonadi-jmbarkei.8CV1R5/mysql.socket'  port: 0  openSUSE package
    160413 14:51:58 [Note] /usr/sbin/mysqld: Normal shutdown
    
    
    
    
    
    
    
    
    160413 14:51:58 [Note] InnoDB: FTS optimize thread exiting.
    160413 14:51:58 [Note] InnoDB: Starting shutdown...
    160413 14:52:00 [Note] InnoDB: Shutdown completed; log sequence number 16172789280
    160413 14:52:00 [Note] /usr/sbin/mysqld: Shutdown complete

Page 3 of 9 FirstFirst 12345 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •