[kmail2] [Bug 362695] Kmail process continues running after exiting with File->quit.

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362695

--- Comment #4 from Christoph Pospiech  ---
Another observation (and work around) - unchecking the button "Settings ->
Configure KMail -> Misc -> Folders -> Empty local trash folder on program exit"
makes the effect disappear - the kmail process terminates gracefully. Looks
like the "Empty local trash folder on program exit" is the culprit or closely
related to it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 362695] Kmail process continues running after exiting with File->quit.

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362695

--- Comment #3 from Christoph Pospiech  ---
Today I scratched all Kmail2 and Akonadi config and data files in $HOME/.config
and $HOME/.local/share - to no avail. The process keeps running after closing
the kmail2 GUI. I haven't seen any Email losses for a while now. So the email
losses I saw earlier seem to be unrelated to this bug.
I made one observation though - I have ticked the option to scratch emails in
trash when closing. The emails are *not* discarded. Means the process hangs
somewhere before erasing trash mails.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

Christoph Pospiech  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Christoph Pospiech  ---
Since the NULL entries by themselves are not considered to be a bug, I opened
another bug report on mail moving (Bug 364243) and I will close this report.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 364243] New: Moving several mails from IMAP inbox to local maildir creates entries with RemoteID NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364243

Bug ID: 364243
   Summary: Moving several mails from IMAP inbox to local maildir
creates entries with RemoteID NULL
   Product: Akonadi
   Version: 16.04
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: critical
  Priority: NOR
 Component: server
  Assignee: kdepim-b...@kde.org
  Reporter: pospiech...@t-online.de

Moving several mails from IMAP inbox to local maildir by selecting and moving
with the mouse is not properly executed. Only one mail arrives as ASCII file in
the target folder. The other mails get a remoteID value NULL in the
pimitemtable, and no file can be found, neither in cash nor in the target
folder. When looking at the mails in Kmail, they appear to be there. Neither
'akonadictl fsck' nor 'akonadictl vacuum' clears this situation (both commands
run to completion). I have not found a way to recover (or find ?) those mails.

Reproducible: Always

Steps to Reproduce:
1. In akonadi, SELECT * FROM `pimitemtable` WHERE `remoteId` IS NULL;
Take note of the number of these entries.
2. In some IMAP inbox in Kmail , select some mails by mouse click (more than
one).
3. Move them into some other folder by mouse left click and hold, moving them
with the
mouse and dropping them into the target folder.
4. In akonadi, re-check via SELECT * FROM `pimitemtable` WHERE `remoteId` IS
NULL;

Actual Results:  
The number of NULL entries increases by n-1, where n is the number of moved
mails.
Only one of the moved mails actually arrives in the target folder.
work around: moving only one mail at a time works fine.

Expected Results:  
All mails should be moved and no NULL entries created.

I will mark this as critical, as I already lost some mails. As soon as there is
a work around how to recover mails with NULL entries, the severity may be
reduced.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

--- Comment #5 from Christoph Pospiech  ---
Perhaps I should stress the point that I believe that there is still an issue.
Daniel Vrátil said it is perfectly normal to have NULL entries, when "the item
has been created in Akonadi and is waiting for the owning resource to store it
in the remote storage". It appears that the mails are all completely downloaded
from IMAP (at least I don't miss any part), but akonadi appears to be confused
about itand it does not happen, if I move one mail at a time.

Christoph

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

--- Comment #4 from Christoph Pospiech  ---
I just managed to create some entries with RemoteID = NULL. I repeated the
experiment - it appears to be reproducible. This is what I did -
1. In akonadi, SELECT * FROM `pimitemtable` WHERE `remoteId` IS NULL;
Take note of the number of these entries.
2. In some IMAP inbox in Kmail , select some mails by mouse click (more than
one).
3. Move them into some other folder by mouse left click and hold, moving them
with the mouse
and dropping them into the target folder.
4. In akonadi, re-check via SELECT * FROM `pimitemtable` WHERE `remoteId` IS
NULL;
Observation: 
1. New NULL entries with collectionID pointing to the target folder, one less
than the number of
mails that were moved. 
2. All mails can be opened in the target folder.
3. The data seems to be there, execute
SELECT * FROM `parttable` WHERE pimItemID IN 
(SELECT id FROM pimitemtable WHERE remoteID IS NULL);
Check field `data` in parttable with a hex-editor.

Is there a way to recreate the mail as ordinary ASCII file in the target folder
?
Christoph

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

--- Comment #3 from Christoph Pospiech  ---
In an earlier command it was written that "It means that the item has been
created in Akonadi and is waiting for the owning resource to store it in the
remote storage". I just observed something that potentially points to a
different direction. I had a couple of NULL entries today, not related to the
trash scenario as described in my previous comment. Apparently, these entries
were pointing to an non-existent entry in ~/.local/share/akonadi/file_db_data.
But they also had a foreign key pointing to a collection. For one of those
collections there happened to be only one mail that I touched/moved into this
collection. I checked in Kmail - and the mail was still there. Means - there is
another entry in the PimItemtable for this mail, and the entry with remoteID =
NULL appears to be really obsolete - a stale duplicate so to speak. My other
(more general) observation is that these entries don't go away, even if the
connection to the IMAP servers is re-established. I did similar checks for the
other mails. - And then decided to eliminate the stale entries via "DELETE FROM
`pimitemtable` WHERE `remoteId` IS NULL;" - knowing that there are delete
cascades into the other tables. Would that be the general solution ?

Christoph Pospiech

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362699] Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

--- Comment #2 from Christoph Pospiech  ---
I just observed another 5 occurrences of RemoteID = NULL. I did some forensic
analysis. Hopefully the following observations help to pin down the problem.
1. Since I am running the akonadi database with my own MySQL server, I could
use phpMyAdmin to do some queries, starting from "SELECT * FROM `pimitemtable`
WHERE `remoteId` is NULL;"
I found that all these entries had a collectionID pointing to the trash can.
2. Apparently they were created by moving entries from an IMAP trash can to the
main trash can. The IMAP server was davmail 4.7.1-2416-1, used as an interface
to outlook.
3. There were three more entries put to the trash can by Kmail directly
- these had a non-NULL RemoteID.
4. Emptying the trash can made the entries with RemoteID = NULL go away
(no surprise, given what I said before).
5. I had a more emails in outlook that I could dispose. I repeated the
following experiment two times.
a. Inside outlook (running in a Win7 VM), put these emails into trash (one or
two at a time).
b. Wait for davmail to replicate the outlook trash into Kmail.
c. Run "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the
result.
d. Move the emails from IMAP trash to main trash.
e. Rerun "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the
difference.
=> One out of three emails disposed that way created a pimitemtable entry with
RemoteID = NULL.
=> This trash can scenario may not be the only one creating this effect. But it
is the least dangerous as these emails are to be disposed anyway - so no harm
done !

Hope this helps !
Christoph Pospiech

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362699] New: Back end MySQL table PimItemTable shows entries with remoteID = NULL

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362699

Bug ID: 362699
   Summary: Back end MySQL table PimItemTable shows entries with
remoteID = NULL
   Product: Akonadi
   Version: 16.04
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: server
  Assignee: kdepim-b...@kde.org
  Reporter: pospiech...@t-online.de

The problem may or may not be related to previous disgraceful exits of Kmail.
There is no reliable way to reproduce the above effect. It is not clear whether
the above entries refer to lost mails.

Reproducible: Couldn't Reproduce


Actual Results:  
Back end MySQL table PimItemTable shows entries with remoteID = NULL

Expected Results:  
Those entries shouldn't exist.

I am using an external MySQL server (/usr/sbin/mysqld).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 362695] Kmail process continues running after exiting with File->quit.

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362695

--- Comment #2 from Christoph Pospiech  ---
I retried (SIGTERMinating and restarting Kmail) a few times and watched
PimItemTable via phpMyAdmin. Creation of entries with remoteId = NULL is not
reproducible, unlike the continuation of the Kmail process. Therefore it may be
unrelated indeed. Using phpMyAdmin I also looked up the date and Mail folder
(aka collection name) of these spurious entries, but I couldn't remember a
missing mail with that date and mail folder. So I am not sure whether I am
loosing mails.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 362695] New: Kmail process continues running after exiting with File->quit.

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362695

Bug ID: 362695
   Summary: Kmail process continues running after exiting with
File->quit.
   Product: kmail2
   Version: 5.1.3
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: critical
  Priority: NOR
 Component: misc
  Assignee: kdepim-b...@kde.org
  Reporter: pospiech...@t-online.de

Kmail doesn't exit after hitting File->quit. Prior to restart, this process has
to be killed by sending SIGTERM to the process. Otherwise it is not possible to
start Kmail again. Occasionally that leaves the Akonadi database in an odd
state (PimItemTable has entries with remoteId = NULL). At least occasionally
this leads to loss of emails - which may bee seen as a secondary effect due to
the disgraceful exit via SIGTERM signal.

Reproducible: Always

Steps to Reproduce:
1. Run Kmail
2. Execute File->quit
3. Inspect process table (e.g. with ps command)

Actual Results:  
Kmail process found running and needs to be killed by sending SIGTERM.

Expected Results:  
No Kmail process left after File->quit .

Akonadi uses external MySQL (/usr/sbin/mysqld) as backend.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 362580] New: akonadi server crashes when recreating the MySQL akonadi database

[Christoph Pospiech via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362580

Bug ID: 362580
   Summary: akonadi server crashes when recreating the MySQL
akonadi database
   Product: Akonadi
   Version: 16.04
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: server
  Assignee: kdepim-b...@kde.org
  Reporter: pospiech...@t-online.de

The akonadi database is maintained on a external MySQL server
(/usr/sbin/mysqld).
The error occurs after upgrading to Kubuntu 16.04, which includes upgrading
mysql-server-5.6 to mysql-server-5.7 . Assuming the akonadi database schema has
changed, I tried to drop the database and recreate it. This crashed when
attempting to create the table PimItemTable.

Reproducible: Always

Steps to Reproduce:
1. akonadictl stop
2. mysql -h localhost -u akonadi -p
3. mysql> drop database if exists akonadi;
4. akonadictl start

Actual Results:  
"CREATE TABLE PimItemTable (id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY, rev
INTEGER NOT NULL DEFAULT 0, remoteId VARBINARY(255), remoteRevision
VARBINARY(255), gid VARBINARY(255), collectionId BIGINT, mimeTypeId BIGINT,
datetime TIMESTAMP DEFAULT CURRENT_TIMESTAMP, atime TIMESTAMP, dirty BOOL, size
BIGINT NOT NULL DEFAULT 0, FOREIGN KEY (collectionId) REFERENCES
CollectionTable(id) ON UPDATE CASCADE ON DELETE CASCADE, FOREIGN KEY
(mimeTypeId) REFERENCES MimeTypeTable(id) ON UPDATE CASCADE ON DELETE RESTRICT)
 COLLATE=utf8_general_ci DEFAULT CHARSET=utf8"
"\nSql error: Invalid default value for 'atime' QMYSQL: Unable to execute
query\nQuery: CREATE TABLE PimItemTable (id BIGINT NOT NULL AUTO_INCREMENT
PRIMARY KEY, rev INTEGER NOT NULL DEFAULT 0, remoteId VARBINARY(255),
remoteRevision VARBINARY(255), gid VARBINARY(255), collectionId BIGINT,
mimeTypeId BIGINT, datetime TIMESTAMP DEFAULT CURRENT_TIMESTAMP, atime
TIMESTAMP, dirty BOOL, size BIGINT NOT NULL DEFAULT 0, FOREIGN KEY
(collectionId) REFERENCES CollectionTable(id) ON UPDATE CASCADE ON DELETE
CASCADE, FOREIGN KEY (mimeTypeId) REFERENCES MimeTypeTable(id) ON UPDATE
CASCADE ON DELETE RESTRICT)  COLLATE=utf8_general_ci DEFAULT CHARSET=utf8"
Unable to initialize database.
terminating service threads
terminating connection threads
stopping db process
Failed to remove runtime connection config file
Application 'akonadiserver' exited normally...


Expected Results:  
PimItemTable should be created along with all other tables and akonadi server
should run.

Work around:
After recreating the above crash, execute the following SQL statements on the
mysql command prompt.
Then redo "akonadictl start".
mysql> use akonadi;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql>  CREATE TABLE PimItemTable (id BIGINT NOT NULL AUTO_INCREMENT PRIMARY
KEY, rev INTEGER NOT NULL DEFAULT 0, remoteId VARBINARY(255), remoteRevision
VARBINARY(255), gid VARBINARY(255), collectionId BIGINT, mimeTypeId BIGINT,
datetime TIMESTAMP DEFAULT CURRENT_TIMESTAMP, atime TIMESTAMP DEFAULT
CURRENT_TIMESTAMP,  dirty BOOL, size BIGINT NOT NULL DEFAULT 0, FOREIGN KEY
(collectionId) REFERENCES CollectionTable(id) ON UPDATE CASCADE ON DELETE
CASCADE, FOREIGN KEY (mimeTypeId) REFERENCES MimeTypeTable(id) ON UPDATE
CASCADE ON DELETE RESTRICT)  COLLATE=utf8_general_ci DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.02 sec)

This is the same SQL statement as in the "Actual Results" tab above, but
"DEFAULT CURRENT_TIMESTAMP" added after "atime TIMESTAMP".

-- 
You are receiving this mail because:
You are watching all bug changes.