[opensuse-kde] Repeatedly having to restart akonadi server after 13.2 upgrade
Hello, I sure would appreciate any suggestions with this problem. I (finally!) upgraded my 13.1 workstation to 13.2, including all updates. Before the update, I would occasionally get the folder lock up problem caused by the akonadi server (once or twice every couple days) that requires the server to be restarted (or log out/log in). IIRC this was a known issue. I hoped it was fixed with the 13.2 release. (I checked the kde akonadi wiki but no help there.) Following my 13.2 upgrade, the problem has become much, much worse. Repeatedly when I click on a message in a folder (read or unread), the folder locks and I get the green Kmail wait screen. At least in the past the condition would sometimes correct itself after a while and free the folder; not any longer, I am now forced to restart the server every time. When I do the server restart, I always get about 50 error messages in the mysql error log. These look like the errors I got in the past each time I would restart, but I can't be sure (I didn't keep the old logs). Fwiw, the log errors look like this: 160421 15:08:48 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist 160421 15:08:48 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them 160421 15:08:48 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_host_by_event_name' has the wrong structure . . . followed by another ~45 of the same "Native table 'performance . schema'.'<name> has the wrong structure" errors, and then this at the end: . . 160421 15:08:48 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't exist 160421 15:08:48 [Note] Reading of all Master_info entries succeded 160421 15:08:48 [Note] Added new Master_info '' to hash table 160421 15:08:48 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.0.22-MariaDB' socket: '/tmp/akonadi-mingus.3qlDQM/mysql.socket' port: 0 openSUSE package 2016-04-21 15:08:48 7fa061eb1700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found. Any suggested solution or workaround? I would hate to have to switch to another client after using Kmail for >dozen years, but this constant akonadi problem has become intolerable. Thanks in advance. Dennis -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On jeudi, 21 avril 2016 16.10:19 h CEST Dennis Gallien wrote:
Hello,
I sure would appreciate any suggestions with this problem.
I (finally!) upgraded my 13.1 workstation to 13.2, including all updates.
Before the update, I would occasionally get the folder lock up problem caused by the akonadi server (once or twice every couple days) that requires the server to be restarted (or log out/log in). IIRC this was a known issue. I hoped it was fixed with the 13.2 release. (I checked the kde akonadi wiki but no help there.)
Following my 13.2 upgrade, the problem has become much, much worse. Repeatedly when I click on a message in a folder (read or unread), the folder locks and I get the green Kmail wait screen. At least in the past the condition would sometimes correct itself after a while and free the folder; not any longer, I am now forced to restart the server every time.
When I do the server restart, I always get about 50 error messages in the mysql error log. These look like the errors I got in the past each time I would restart, but I can't be sure (I didn't keep the old logs).
Fwiw, the log errors look like this:
160421 15:08:48 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist 160421 15:08:48 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them 160421 15:08:48 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_host_by_event_name' has the wrong structure . . . followed by another ~45 of the same "Native table 'performance . schema'.'<name> has the wrong structure" errors, and then this at the end: . . 160421 15:08:48 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't exist 160421 15:08:48 [Note] Reading of all Master_info entries succeded 160421 15:08:48 [Note] Added new Master_info '' to hash table 160421 15:08:48 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.0.22-MariaDB' socket: '/tmp/akonadi-mingus.3qlDQM/mysql.socket' port: 0 openSUSE package 2016-04-21 15:08:48 7fa061eb1700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found.
Any suggested solution or workaround? I would hate to have to switch to another client after using Kmail for >dozen years, but this constant akonadi problem has become intolerable.
Thanks in advance.
Dennis
I don't think it could help a lot but. akonadictl vacuum akonadictl fsck can't damage more. The errors you have look like and older mysql/mariad db structure which have escape upgrade procedure ( rpm install running only those on system wide server ) Sorry I'm using a central postgresql instance, so I'm not aware of all the details for mysql/mariadb but I would check the package of those and check the postin action to replay exactly the same to your local akonadi server. kmail exporter can perhaps help you to dump the actual data, then create a fresh one and reimport (but don't trust this tool as a silver bullet, it lack certainly maturity) And nobody like to loose some setup. Hope this give you some direction where to check -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Apr 22 03:33:18 PM Bruno Friedmann wrote:
I don't think it could help a lot but. akonadictl vacuum akonadictl fsck
can't damage more.
The errors you have look like and older mysql/mariad db structure which have escape upgrade procedure ( rpm install running only those on system wide server )
Sorry I'm using a central postgresql instance, so I'm not aware of all the details for mysql/mariadb
but I would check the package of those and check the postin action to replay exactly the same to your local akonadi server.
kmail exporter can perhaps help you to dump the actual data, then create a fresh one and reimport (but don't trust this tool as a silver bullet, it lack certainly maturity) And nobody like to loose some setup.
Hope this give you some direction where to check --
Bruno Friedmann
Thank you for the suggestions, Bruno. I tried akonadictl, as you suspected it did not help. Sorry but I don't know what the "postin action" is or how to execute it. The kmail export/import seems worth a try. When you write "create a fresh one" are you referring to deleting and reinstalling akonadi and kmail including removing the mysql database? Thanks again for the assistance. Dennis Gallion -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On samedi, 23 avril 2016 11.26:47 h CEST Dennis Gallien wrote:
On Fri, Apr 22 03:33:18 PM Bruno Friedmann wrote:
I don't think it could help a lot but. akonadictl vacuum akonadictl fsck
can't damage more.
The errors you have look like and older mysql/mariad db structure which have escape upgrade procedure ( rpm install running only those on system wide server )
Sorry I'm using a central postgresql instance, so I'm not aware of all the details for mysql/mariadb
but I would check the package of those and check the postin action to replay exactly the same to your local akonadi server.
kmail exporter can perhaps help you to dump the actual data, then create a fresh one and reimport (but don't trust this tool as a silver bullet, it lack certainly maturity) And nobody like to loose some setup.
Hope this give you some direction where to check --
Bruno Friedmann
Thank you for the suggestions, Bruno.
I tried akonadictl, as you suspected it did not help.
Sorry but I don't know what the "postin action" is or how to execute it.
The kmail export/import seems worth a try. When you write "create a fresh one" are you referring to deleting and reinstalling akonadi and kmail including removing the mysql database?
Thanks again for the assistance.
Dennis Gallion
Hi Dennis. When I'm talking about post action in rpm this is for example what happen in mariadb just after the installation %post %service_add_post mysql.service mysql@.service mysql.target mysql@default.service # Use %%tmpfiles_create when 13.2 is oldest in support scope %{_bindir}/systemd-tmpfiles --create %{_tmpfilesdir}/mysql.conf || : # SLE11 Migration support for i in protected tmp; do rmdir "$datadir"/.$i 2>/dev/null || : done # Remove any messages that could've been in place about the upgrade rm -f %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} # During package rename (migration maria->mysql-community-server), # there might be config file move and we get rpmsave that we should keep if [ -f %{_sysconfdir}/my.cnf.rpmsave ]; then mv %{_sysconfdir}/my.cnf{,.rpmnew} mv %{_sysconfdir}/my.cnf{.rpmsave,} cat >> %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} << EOF WARNING: %{_sysconfdir}/my.cnf.rpmsave file detected! This probably means that you are migrating from different variant of MySQL. Your configuration was left intact and you can see the new configuration in %{_sysconfdir}/my.cnf.rpmnew EOF fi # warn on first run datadir="`%{_bindir}/my_print_defaults mysqld mysql_server | sed -n 's|--datadir=||p'`" [ -n "$datadir" ] || datadir="%{_localstatedir}/lib/mysql" if [ -d "$datadir/mysql" ]; then touch "$datadir/.run-mysql_upgrade" fi if [ \! -f "$datadir/mysql_upgrade_info" ]; then if [ $1 -eq 1 ]; then cat >> %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} << EOF %(cat %{_sourcedir}/README.install) EOF fi else MYSQLVER="`echo %{version} | sed 's|\.[0-9]\+$||'`" if [ -f "$datadir/mysql_upgrade_info" ] && \ [ -z "`grep "^$MYSQLVER" "$datadir/mysql_upgrade_info" 2> /dev/null`" ]; then cat >> %{_localstatedir}/adm/update-messages/%{name}-%{version}-%{release} << EOF WARNING: You are upgrading from different stable version of MySQL! Your database will be migrated automatically during next restart of MySQL. Before you do that make sure you have up to date backup of your data. It should be mainly in $datadir directory. EOF fi fi exit 0 This is valid for what is stored in /var/lib/mysql (/var/lib being %datadir) So once you have 2 times a copy of your pim stack data and also used once kmail exporter to be on a safe side you could do something like that datadir=~/.local/share/akonadi touch "$datadir/.run-mysql_upgrade" and also have a look at https://build.opensuse.org/package/view_file/server:database/mariadb/mysql-s... especially the upgrade part it should give you some clue of what to run to have an upgraded mysql. if, and please verify twice where the mysql data are located. cause I'm not able to have a mysql/mariadb to be 100% of the information I'm giving to you. You should also have a .my.cnf file at that location, it is worth to check and compare it against the system wide ... /me is happy to have always used system-wide server configuration, more easy to maintain, backup and upgrade. :-) Finally, if nothing works, then yes the absolute medics, is to logout, in console mode cleanup completely all trace of akonadi & kmail, korganizer, kontact and so from your .local and .kde4 if it still exist. then login, and try to use kmail importer, perhaps you will be enough lucky to be able to restore everything. the database being reinitialized new. Good luck -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sat, Apr 23 09:08:44 PM Bruno Friedmann wrote:
. . .
Finally, if nothing works, then yes the absolute medics, is to logout, in console mode cleanup completely all trace of akonadi & kmail, korganizer, kontact and so from your .local and .kde4 if it still exist.
then login, and try to use kmail importer, perhaps you will be enough lucky to be able to restore everything. the database being reinitialized new.
Good luck --
Bruno Friedmann
Bruno, thanks so very much for all the work. That is awesome! Will give it a try. From having read additional posts around the web about this problem, it won't be a surprise if mysql is the culprit and I will end up doing an in- place reinstall/rebuild db/migration. We shall see, Again, thanks for all the help! Dennis -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Thu, Apr 21 04:10:19 PM Dennis Gallien wrote:
Before the update, I would occasionally get the folder lock up problem caused by the akonadi server (once or twice every couple days) that requires the server to be restarted (or log out/log in).
Following my 13.2 upgrade, the problem has become much, much worse. Repeatedly when I click on a message in a folder (read or unread), the folder locks and I get the green Kmail wait screen. At least in the past the condition would sometimes correct itself after a while and free the folder; not any longer, I am now forced to restart the server every time.
When I do the server restart, I always get about 50 error messages in the mysql error log like this . . .
160421 15:08:48 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist 160421 15:08:48 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them 160421 15:08:48 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure 160421 15:08:48 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure 160421 15:08:48 [ERROR] Native table
etc.
I'm sending this reply to both the kde and user lists as there have been many kmail/akonadi issues posted on both, and what I found may be useful for kmaill users on both lists . . . My plan was to delete all akonadi related files, have the server rebuild them, manually re-populate the account resources, and re-link the mail store directory to the Local Folders resource. Before doing that, I created a full kmail backup with pimsettingsexporter. and for safety sake attempted to create an archive file with the kmail folder archive function. "Attempted" only because the folder archive function failed. Working this problem I stumbled on to what was causing kmail to lock up requiring a server restart: bad message data in some of the folders. The folder archive process will fail when it encounters a message it cannot process. All the user gets is a terse message saying just that, along with the folder name. In the incomplete archive file I could locate the problem folder and the number of messages successfully retrieved before the failing message. In kmail, permanently deleting messages including the likely "bad" message (typically required several iterations), finally enabled the archive process to complete for that folder. This was necessary in 6 of my ~50 local folders. Before proceeding with rebuilding akonadi, in kmail I noticed I could click on a message and kmail did not lock up. I've been rigorously testing this for 2 days and have not had one single lock up. Note that the lock ups did not occur by trying to access a "bad" message. In fact, it happened clicking on a good message in a folder without any problem. Any folder. It seems that just the presence of the bad messages in some folders can create a condition which subsequently causes kmail and/or akonadi to lock up. I cannot say whether the problem would have resolved if, after rebuilding the akonadi fileset, I had re-linked to my existing mail store or created a new one from the pimsettingsexporter file - the bad messages would have still been there. Nor is there any way I could find that informs the user what makes a message "bad" in this sense. As far as all the "performance schema" errors thrown by mysql, those are all red herrings and should not even be in the error file; they are near certainly bogus and should be ignored. (Side point: running akonadictl start in the terminal is informative and shows the database tables being checked; these error messages are unrelated.) Hopefully some of this information is useful. Thank much to those who replied with suggested solutions. --dg -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (2)
-
Bruno Friedmann -
Dennis Gallien