Bug 26096

Here is the report, tests 1-13:

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/edward/.config/akonadi/akonadiserverrc':
[Debug]
Tracer=null

[%General]
Driver=QMYSQL
ExternalPayload=false
SizeThreshold=4096

[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/tmp/akonadi-edward.q20aDk/mysql.socket"
Password=
ServerPath=/usr/sbin/mysqld
StartServer=true
User=


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: /usr/sbin/mysqld  Ver 10.3.20-MariaDB for Linux on x86_64 (Mageia MariaDB Server)


Test 5:  ERROR
--------

MySQL server log contains errors.
Details: The MySQL server error log file '<a href="/home/edward/.local/share/akonadi/db_data/mysql.err">/home/edward/.local/share/akonadi/db_data/mysql.err</a>' contains errors.

File content of '/home/edward/.local/share/akonadi/db_data/mysql.err':
2020-01-17 10:56:56 0 [Note] InnoDB: Using Linux native AIO
2020-01-17 10:56:56 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-01-17 10:56:56 0 [Note] InnoDB: Uses event mutexes
2020-01-17 10:56:56 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-01-17 10:56:56 0 [Note] InnoDB: Number of pools: 1
2020-01-17 10:56:56 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-01-17 10:56:56 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-01-17 10:56:56 0 [Note] InnoDB: Completed initialization of buffer pool
2020-01-17 10:56:56 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-01-17 10:56:56 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-01-17 10:56:56 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-01-17 10:56:56 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-01-17 10:56:56 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-01-17 10:56:56 0 [Note] InnoDB: Waiting for purge to start
2020-01-17 10:56:56 0 [Note] InnoDB: 10.3.20 started; log sequence number 485381748; transaction id 17044211
2020-01-17 10:56:56 0 [Note] InnoDB: Loading buffer pool(s) from /data/configuration/home/.local/share/akonadi/db_data/ib_buffer_pool
2020-01-17 10:56:56 0 [Note] InnoDB: Buffer pool(s) load completed at 200117 10:56:56
2020-01-17 10:56:56 0 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
2020-01-17 10:56:56 0 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
2020-01-17 10:56:56 6 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1017: Can't find file: './mysql/' (errno: 2 "No such file or directory")
2020-01-17 10:56:56 0 [Note] Reading of all Master_info entries succeeded
2020-01-17 10:56:56 0 [Note] Added new Master_info '' to hash table
2020-01-17 10:56:56 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.3.20-MariaDB'  socket: '/tmp/akonadi-edward.q20aDk/mysql.socket'  port: 0  Mageia MariaDB Server
2020-01-17 10:56:56 9 [ERROR] InnoDB: Table `mysql`.`innodb_table_stats` not found.


Test 6:  ERROR
--------

MySQL server default configuration not found.
Details: The default configuration for the MySQL server was not found or was not readable. Check your Akonadi installation is complete and you have all required access rights.

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/edward/.local/share/akonadi/mysql.conf">/home/edward/.local/share/akonadi/mysql.conf</a> and is readable.

File content of '/home/edward/.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=128M

# 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:  SUCCESS
--------

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


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:  SUCCESS
--------

Akonadi server process registered at D-Bus.
Details: The Akonadi server process is registered at D-Bus which typically indicates it is operational.

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:  SUCCESS
--------

Resource agents found.
Details: At least one resource agent has been found.

Directory listing of '/usr/share/akonadi/agents':
akonadiindexingagent.desktop
akonotesresource.desktop
archivemailagent.desktop
birthdaysresource.desktop
contactsresource.desktop
davgroupwareresource.desktop
ewsmtaresource.desktop
ewsresource.desktop
facebookresource.desktop
followupreminder.desktop
googlecalendarresource.desktop
googlecontactsresource.desktop
icaldirresource.desktop
icalresource.desktop
imapresource.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
tomboynotesresource.desktop
unifiedmailboxagent.desktop
vcarddirresource.desktop
vcardresource.desktop

Environment variable XDG_DATA_DIRS is set to '/home/edward/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/'

Created attachment 11460 [details]
akonada selftest report

The full report from akonadiselftest.

CC: (none) => true.bugman

More text from the Akonadi server self-test:

"""
Details

The default configuration for the MySQL server was not found or was not readable.  Check your Akonadi installation is complete and you have all required access rights.
"""

As another test, I added a new user with empty home directory.  The Akonadi server self-test failed on Test 6 (and the last tests as well).  I'll attach that log file next.

Created attachment 11461 [details]
akonada selftest report for a new user with an empty home directory.

Note that comment 1 tests 1-13 are a *partial* copy of the O/P in the comment 2 attachment, which shows additional tests 14-17, all ERROR.
The comment 4 attachment O/P is similar (but not identical in detail).

Trying this as per the instructions (comment 0), I am stopped by ignorance of Korganizer. Under Mate, not Plasma, with:
 akonadi-19.04.0-1.mga7
 mariadb-10.3.20-1.mga7
 korganizer-19.04.0-1.mga7
and having done no setup or configuration that I recall.
> 1. Open KOrganizer.
> 2. Double click on any day.
> 3. Add 'test' to the title and click 'Ok'
except I do *not* get an error dialogue, but
"You created an incident in a calender which is currently filtered out
On the left sidebar, enable it in the calendar manager to see the incident".

Beats me. I do not know how to drive this thing. I shall attach a screenshot + explanation.

Created attachment 11465 [details]
KOrganizer window after creating a test even

I followed the instructions, created an event for the 18th titled "Test" (default all day, blocks others), OK, got no error but the comment bottom right, but could not - did not know how to - show the event created.
In fact I re-did this repeatedly. Clicked every likely looking icon, ditto Golwg=View menu items. No joy. But the fact that the 18th is dark blue suggests there is an event there.
See the following...

CC: (none) => lewyssmith

Created attachment 11466 [details]
Akonadi self test summary showing failures

 $ akonadiselftest
produced this final window, which accords with the complaint.

Assigning to the KDE/Plasma team.

Source RPM: (none) => akonadi-19.04.0-1.mga7.src.rpm
Assignee: bugsquad => kde

For comment 6, after double clicking on a date did you select "Personal Calendar" within the dialog window?  If so, you need to select "Personal Calendar in the bottom left frame of the KOrganizer window to see that calendar.

As for the 18th being dark blue, that is just a selection (via mouse) that you can then right click on to add events.  Anyway, I've never seen the errors in the 'akonadiselftest' in comment 7 in any previous Mageia versions.

More testing shows that a new user fails the 'akonadiselftest', however the calendar can be modified.  So I guess my issue is that the newer akonadi version cannot handle the SQL databases from my previous Mageia 6 install.  Is there an easy way to test the v19.04.3 tag of akonadi to see if any of the numerous bug fixes from the v19.04.0 make this issue disappear?

I guess the easiest work around would be to open each akonadi component (calendar, todo lists, alarms, contacts, etc.), export them to text file, nuke the akonadi directories, and reimport the lot.

As a workaround, the 'export -> nuke akonadi -> reimport' route works fine.  The workaround steps are:

1. Open KOrganizer, 'File->Export->Export as iCalendar', and save the file.

2. Open KAddressBook, 'File->Export->Export vCard 4.0...', and save the file.

3. For KMail, KAlarm, and KJots, I did nothing as these were unused.  I'm not sure what you would do for these.

4. Log into a virtual terminal with no X, e.g. run 'init 3' as root.

5. Nuke Akonadi:

$ rm -rf ~/.cache/akonadi*
$ mv ~/.config/akonadi ~/.config/akonadi_old
$ mv ~/.local/share/akonadi ~/.local/share/akonadi_old

6. Restart X, e.g. 'init 5' as root.

7. Log into the plasma desktop and let akonadi reconfigure itself.

8. Open KOrganizer, 'File->Import->Import Calendar', and select the saved file.

9. Open KAddressBook, 'File->Import->Import vCard...', and select the saved file.

Now KOrganizer and KAddressBook are functional again, despite 'akonadiselftest' still failing tests 6, 14, 15, 16, and 17 (test 5 no longer fails, but that could be due to me manually configuring the broken MariaDB installation).

Please run as user
$ mysql_upgrade -u akonadi --socket=/run/user/1000/akonadi/mysql.socket

Replace /1000/ with the uid of the current user.

The script is supposed to check and correct the mysql system tables, and thus correct the errors in mysql.err.

My guess is that a previous migration script failed, and the script might be corrected meanwhile.

Another script to check the akonadi user tables is
$ akonadictl fsck

CC: (none) => bequimao.de

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED