Bug 23627 - Kmail will not start due to akonadi/MySQL unavailable.
Summary: Kmail will not start due to akonadi/MySQL unavailable.
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA6-64-OK
Keywords: validated_update
Depends on:
Blocks: 23035
  Show dependency treegraph
 
Reported: 2018-10-02 13:36 CEST by Maurice Batey
Modified: 2019-02-17 01:32 CET (History)
8 users (show)

See Also:
Source RPM: akonadi-17.12.2-1.mga6.src.rpm, kmail-17.12.2-1.mga6.src.rpm
CVE:
Status comment:


Attachments
List of installed packages (2.04 KB, text/plain)
2019-02-13 19:05 CET, Ulrich Beckmann
Details

Description Maurice Batey 2018-10-02 13:36:50 CEST
Description of problem:


Version-Release number of selected component (if applicable):

   akonadi-18.04.1-2.mga7.src.rpm

How reproducible:


Steps to Reproduce:
1. In terminal session, start kmail

2. Result: 

$ kmail
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Did not find MySQL server default 
configuration 
(mysql-global.conf)
org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...


3. Tried to start akonadi : 

  $ akonadictl start
    Connecting to deprecated signal 
    QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
    [mab@pc18 ~]$ org.kde.pim.akonadiserver: Did not find MySQL server 
    default configuration (mysql-global.conf)
    org.kde.pim.akonadiserver: Failed to remove runtime connection config 
file
    org.kde.pim.akonadicontrol: Application 'akonadiserver' exited 
normally...

4. Check:

$  locate mysql-global.conf
/etc/akonadi/mysql-global.conf
/usr/share/digikam/database/mysql-global.conf

$ systemctl status mysqld
Unit mysqld.service could not be found.

# systemctl start mysqld
Failed to start mysqld.service: Unit mysqld.service not found.
Marja Van Waes 2018-10-02 19:31:07 CEST

Assignee: bugsquad => kde
CC: (none) => marja11

Stéphane Pontier 2018-10-08 07:54:19 CEST

CC: (none) => stephane.pontier

Ulrich Beckmann 2018-10-12 11:06:47 CEST

CC: (none) => bequimao.de

Comment 1 James Kerr 2018-11-23 11:20:25 CET
This bug also happens with other kde-apps which use akonadi, such as korganizer and kaddressbook.

CC: (none) => jim
Source RPM: akonadi-18.04.1-2.mga7.src.rpm => akonadi-18.08.2-1.mga7.src.rpm

Comment 2 David GEIGER 2018-11-23 13:48:49 CET
Is the package mariadb installed?

CC: (none) => geiger.david68210

Comment 3 James Kerr 2018-11-23 14:04:12 CET
seems to be:

$ rpm -qa | grep mariadb
mariadb-client-10.3.11-1.mga7
lib64mariadb-devel-10.3.11-1.mga7
mariadb-extra-10.3.11-1.mga7
mariadb-common-core-10.3.11-1.mga7
lib64mariadb3-10.3.11-1.mga7
mariadb-core-10.3.11-1.mga7
mariadb-common-10.3.11-1.mga7
mariadb-10.3.11-1.mga7
lib64mariadb18-10.1.28-1.mga7
Comment 4 James Kerr 2018-11-23 14:23:25 CET
On mga6, I also have lib64mariadb-embedded18, but there does not seem to be an equivalent package for cauldron.
Comment 5 Maurice Batey 2018-11-24 14:01:09 CET
Same problem on newly-installed Plasma Mageia-7-beta1-x86_64.
  (No such problem on Mageia-6.1)
Comment 6 Lewis Smith 2018-12-07 20:21:15 CET
M7beta1: akonadi-18.08.3-1.mga7
[I do not think this happened with Mageia 6].
(In reply to James Kerr from comment #1)
> This bug also happens with other kde-apps which use akonadi, such as
> korganizer and kaddressbook.
These KDE programs (at least) want Akonadi in vain:-
 KJots
 KAlarm
 KMail/PIM Import
 KMail
 PIM setting exporter
 KAddressBook
 KOrganiser

Some offer to start it, then like all the others, say:
 "The Akonadi personal information management service is not operational"
below which is a "Details" button which does nothing.
 $ ps -ax | grep akonadi
 21234 pts/0    S+     0:00 grep --color akonadi

I have raised the priority because so many applications, some significant, are blocked. I think the bug title could be clarified, but leave somebody nearer the centre to do that.
This has nothing to do with databases (I think, unless there are two issues).

Priority: Normal => High
CC: (none) => lewyssmith

Curtis Hildebrand 2018-12-15 23:37:02 CET

CC: (none) => curtis_mageia

Comment 7 Lewis Smith 2018-12-17 18:12:14 CET
M7 beta1 17 Dec 2018, Classic, 6 desktops, updated (1Gb, >1000 updates!).
Running under Cinnamon from SDDM. *All* the KDE programs cited above now start correctly. So the problem seems to be fixed; thanks to whoever.
I am closing the bug. If anybody objects, please re-open it. I will if other desktops still show the fault - which I do not expect.

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

Comment 8 Maurice Batey 2018-12-17 19:02:57 CET
I'm sorry to say that - on my 64-bit Plasma install via classic iso and fully Cauldron-updated a few minutes ago and rebooted - Kmail still fails as described earlier (as does Kompozer: Bug 23628).

No improvement here on Plasma install, so Re-opened.

Resolution: FIXED => (none)
Status: RESOLVED => REOPENED

Comment 9 James Kerr 2018-12-17 20:11:15 CET
I see the same as Maurice

@Lewis Do you have testing repo's enabled? A major update of QT5 and KF5 is in the course of being packaged. I think we should wait until those packages have been pushed to the release repo's before concluding definitively that this bug is fixed.
James Kerr 2018-12-20 23:05:25 CET

Keywords: (none) => 7beta1

Comment 10 James Kerr 2019-01-06 20:29:23 CET
Today's update to akonadi-18.12.0-2 has fixed this bug for me.
Comment 11 Maurice Batey 2019-01-07 11:39:04 CET
Although the akonadi update has enabled Kmail to start up apparently normally, it is still unusable here, because:

  (1) Although it has obviously picked up the maildir directory ~/mail (as it has the correct subfolders, each of which shows how many messages it contains), the Message-List and Message-Body panes are *empty* (even after several hours have passed during which Akonadi & Co might have been indexing the email DB).

I suspect the indexing is simply not happening, so it seems there is a missing stage or two still.

Will keep trying updates to see if the jigsaw completes itself...

(N.B. Kompozer (bug 23628) is still a non-starter)
Comment 12 Ulrich Beckmann 2019-01-11 20:28:35 CET
Akonadi works here now, too.

The list of mailings of 2 IMAP accounts, one of these GMail, is not exposed either.

I suggest to close this thread as fixed and open another one for better readability.

IMO kompozer has no reference to KDE Plasma!

Ulrich

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED

Comment 13 Maurice Batey 2019-01-11 21:55:51 CET
Kmail still unusable here on fully-updated Plasma5 Mageia-7 on nVidia desktop and also on Intel HP 450 Probook, although the situation is a big step forward from the previus 'cliff-edge' startup collapse.

  There seems to be some missing link between Kmail's multi-folder knowledge of the contents of the maildir ~/mail DB, and totally empty Message-List & Message-Body panes.

Attempts to re-index the email DB do not succeed, even when left to run overnight, with zero evidence of improvement.
Comment 14 Maurice Batey 2019-01-13 20:27:39 CET
Out of curiosity, I cloned my Mageia-6.1 /home (which has a 100% working Kmail) onto Mageia-7, to see what its Kmail made of it:
  Not the slightest difference, despite the fact that the clone of Mga6.1 /home has a squeaky clean akonadi/.baloo DB:

  Mga7's Kmail opened correctly EXCEPT that the Message-List & Message-body panes remain empty, even though all the subfolders know how many messages each contains.

So - a missing link between email DB and Kmail's listings in Message-List & Meaasge-Body panes...
Comment 15 Maurice Batey 2019-02-03 18:44:38 CET
Happy to report that with the advent of Kmail-18.12.1-2mga7 in today's Cauldron update on both desktop and laptop real hardware, Kmail is behaving normally and now displays in Header-Pane and Message-Pane.

So far as I am concerned this bug can now be closed, thank godness. :-)
Comment 16 David GEIGER 2019-02-08 09:08:11 CET
So time to fix this issue for mga6 too!

Status: RESOLVED => REOPENED
Hardware: x86_64 => All
Source RPM: akonadi-18.08.2-1.mga7.src.rpm => akonadi-17.12.2-1.mga6.src.rpm
Resolution: FIXED => (none)
Version: Cauldron => 6

Comment 17 David GEIGER 2019-02-08 09:14:38 CET
Assigning to QA,

Advisory:
========================

Some users reported that kmail doesn't work properly. This come from some packaging issues and from some missing required dependencies.
So this update fixes those issues.

- akonadi: fix unavailable MySQL server default configuration
- kmail require akonadi-mime (mga#24296)
- kmail require kmailtransport
- kmail recommend sasl2-plugin-kdexoauth2 (mga#23035)
- kmail require ktnef, pim-sieve-editor and grantlee-editor

========================

Packages in 6/core/updates_testing:
========================
akonadi-17.12.2-1.1.mga6.x86_64.rpm
lib64akonadiprivate5.x86_64.rpm
lib64kf5akonadicore5.x86_64.rpm
lib64kf5akonadiagentbase5.x86_64.rpm
lib64kf5akonadiwidgets5.x86_64.rpm
lib64kf5akonadixml5.x86_64.rpm
lib64kf5akonadi-devel.x86_64.rpm
kmail-17.12.2-1.1.mga6.x86_64.rpm
ktnef-17.12.2-1.1.mga6.x86_64.rpm
kmail-handbook-17.12.2-1.1.mga6.noarch.rpm
lib64kmailprivate5-17.12.2-1.1.mga6.x86_64.rpm

akonadi-17.12.2-1.1.mga6.i586.rpm
libakonadiprivate5.i586.rpm
libkf5akonadicore5.i586.rpm
libkf5akonadiagentbase5.i586.rpm
libkf5akonadiwidgets5.i586.rpm
libkf5akonadixml5.i586.rpm
libkf5akonadi-devel.i586.rpm
kmail-17.12.2-1.1.mga6.i586.rpm
ktnef-17.12.2-1.1.mga6.i586.rpm
libkmailprivate5-17.12.2-1.1.mga6.i586.rpm


Source RPM: 
========================
akonadi-17.12.2-1.1.mga6.src.rpm
kmail-17.12.2-1.1.mga6.src.rpm

Source RPM: akonadi-17.12.2-1.mga6.src.rpm => akonadi-17.12.2-1.mga6.src.rpm, kmail-17.12.2-1.mga6.src.rpm
Assignee: kde => qa-bugs
Keywords: 7beta1 => 6.1

Comment 18 Maurice Batey 2019-02-08 12:38:14 CET
No longer a problem here on either Mageia-6.1 or Magaei-7-beta2.
  Kmail working well on both now. Let's hope it stays that way...
Comment 19 Lewis Smith 2019-02-08 19:19:07 CET
@Maurice: first, thank you for all your work with this awkward problem.
For Mageia *6*, can you confirm the version of the packages cited in comment 17.
If everything works for you (perhaps already) with these updated pkgs, please MGA6-64-OK in Whiteboard, and Validate the update in Keywords.
Comment 20 Maurice Batey 2019-02-08 19:31:52 CET
> can you confirm the version of the packages cited in comment 17

  There are a lot of packages cited there, Lewis! 
Which ones are you interested in?

FYI, Urpmi has just confirmed that my Mageia-6.1 "Packages are up to date".
Comment 21 Lewis Smith 2019-02-09 10:29:52 CET
(In reply to Maurice Batey from comment #20)
> Which ones are you interested in?
If you do (M6):
 $ rpm -q kmail
 $ rpm -q akonadi
you will see the essential, the other pkgs should conform. I currently see 17.12.2-1.mga6 for the two, pre-update.
Comment 22 Maurice Batey 2019-02-09 12:16:51 CET
I see:

$  rpm -q kmail
kmail-17.12.2-1.mga6
$  rpm -q akonadi
akonadi-17.12.2-1.mga6

Whiteboard: (none) => MGA6-64-OK
Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 23 Ulrich Beckmann 2019-02-09 20:51:48 CET
I don't understand the procedure here in this bug report.

It was a bugreport on Cauldron. I saw the Cauldron issues on my machine, too.
I had no Mga6 issue that was not covered by another bug reports. Actually KMail, Akonadi, and Kontact are working fine. So I as a QA tester would not know what to test, except to test for regressions.

The Mga6 side should have required a separate bug report.

@ Maurice 
Pse do not set MGA6-64-OK and validated_update at the same time!
Thus any other tester has no chance to object. It should require a few days.

Best regards
Ulrich

Keywords: validated_update => (none)

Comment 24 Maurice Batey 2019-02-09 23:23:14 CET
Ulrich, see request in Comment 19...
Comment 25 David GEIGER 2019-02-09 23:55:36 CET
If it fix bug for Cauldron so it should simply do the same for mga6!

Here with the bug 23035 we would simply ensure that kmail works properly! nothing more!
Comment 26 Lewis Smith 2019-02-10 13:21:43 CET
(In reply to Maurice Batey from comment #22)
> I see:
> $  rpm -q kmail
> kmail-17.12.2-1.mga6
> $  rpm -q akonadi
> akonadi-17.12.2-1.mga6
which shows that your M6 system does *not* include the update. This (& 23035) are both with QA to test. The fact that your system reports up-to-date is because both these updates have yet to be formally tested & pushed.
I have removed the OK, it was not justified. See comment 19.

@ Maurice: up to you now to test the formal update from Update Testing repo as per comment 17. And if you can do 23035 as well, please do.

(In reply to Ulrich Beckmann from comment #23)
> I don't understand the procedure here in this bug report.
Yes, it is confusing.

> I had no Mga6 issue that was not covered by another bug reports. Actually
> KMail, Akonadi, and Kontact are working fine. So I as a QA tester would not
> know what to test, except to test for regressions.
Correct.
 
> The Mga6 side should have required a separate bug report.
Perhaps, but it is covered here now c17.
 
> Pse do not set MGA6-64-OK and validated_update at the same time!
> Thus any other tester has no chance to object. It should require a few days.
If a test justifies the OK, the update will *not* normally be looked at again (except perhaps for the 'other' architecture). Validation is typically done when the last of required OKs is done. Due to QA workload, currently 1 mostly suffices. It can be un-done if somebody sees fit.

Keywords: 6.1 => (none)
Whiteboard: MGA6-64-OK => (none)

Comment 27 Maurice Batey 2019-02-10 13:33:45 CET
> your M6 system does *not* include the update. This (& 23035) are both with QA 
> to test... I have removed the OK, it was not justified. 

   Apologies for jumping gun... (Misunderstood what you wanted me to do.)

> up to you now to test the formal update from Update Testing repo as per comment > 17. And if you can do 23035 as well, please do.

  Need to re-familiarise with Use of Updates Testing first...

  Cannot check 23035 as I do not use IMAP.
Comment 28 Maurice Batey 2019-02-10 13:48:55 CET
> up to you now to test the formal update from Update Testing repo 
> as per comment 17. 

P.S. Problem for me here: I don't have a 'Test' Mga6 install, and would not want to risk compromising my Production install of Mga6.1 with anything from Test - except as last resort (if no-one has a 'Test' Mga6) with appropriate backup and fingers crossed...
Ulrich Beckmann 2019-02-11 00:10:31 CET

Blocks: (none) => 23035

Comment 29 Lewis Smith 2019-02-11 21:30:57 CET
OK Maurice, don(t worry. The two updates will soon be done by regular QA people.
As for having a separate 'test' machine - I never have. The only real danger is an update that leaves the system unbootable. Otherwise, most updates that go wrong (rare) either do not update at all (safe), or can be 'undone' with
 $ urpmi --downgrade <packages>
Comment 30 Maurice Batey 2019-02-12 00:19:19 CET
Comment 26:
 > up to you now to test the formal update from Update Testing repo as per 
 > comment 17. 

P.S. Which particular packages are we talking about here?
   Might be able to do something tomorrow...
Comment 31 Maurice Batey 2019-02-12 00:20:03 CET
 > Might be able to do something tomorrow..

  i.e. Mageia-6.1
Comment 32 Ulrich Beckmann 2019-02-13 19:05:57 CET
Created attachment 10740 [details]
List of installed packages

I could now upgrade the list of packages sucessfully and will look for regressions.

Ulrich
Comment 33 David GEIGER 2019-02-14 21:59:06 CET
Can this update be validated, please?
Comment 34 Ulrich Beckmann 2019-02-14 22:54:12 CET
No regression found.
I tested several functions of akonadictl, too.

Ulrich

Whiteboard: (none) => MGA6-64-OK

Comment 35 Ulrich Beckmann 2019-02-16 21:24:06 CET
I think, waited enough time. Validating.

Keywords: (none) => validated_update

Comment 36 Mageia Robot 2019-02-17 01:32:41 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2019-0013.html

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.