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

            Bug ID: 455377
           Summary: Akonadi/Kalarm Constant Disk Access & High CPU Usage +
                    Creates 700,000 Files
           Product: kalarm
           Version: 2.13.0
          Platform: Ubuntu Packages
                OS: Linux
            Status: REPORTED
          Severity: major
          Priority: NOR
         Component: Akonadi
          Assignee: djar...@kde.org
          Reporter: ubu...@ozzyfrank.com
  Target Milestone: ---

SUMMARY
***
After noticing my HD light blinking for no apparent reason, I ran *top* in the
terminal, which revealed 2 *akonadi_kalarm_* processes using 25% CPU each, and
figured this was either reading from or writing to disk (turns out it was
creating a file every second or two). After finding no info on this in regards
to Kalarm online, I found many experiencing a similar thing with Akonadi &
Kmail, so implemented what I learned from those, as well as what I discovered
myself (the following is as succinct as possible, while still giving as much
info as I can):

After halting Akonadi with *akonadictl stop*, then restarting with *akonadictl
start*, the output - which kept repeating in an endless loop - was:

org.kde.pim.akonadiserver: Error while handling command ModifyItems on
connection akonadi_kalarm_resource_1 (0x55c03dbecdd0)
KAlarmResourceCommon::setCollectionCompatibility: 14 -> QFlags(0x2) 0
KAlarmResourceCommon::modifyCollectionJobDone
The hash has changed.
The hash has changed.
KAlarmResourceCommon::setCollectionCompatibility: 26 -> QFlags(0x2) 0
KAlarmResourceCommon::modifyCollectionJobDone
The hash has changed.
The hash has changed.

Ascertaining that the full name of the process show in *top* was
*akonadi_kalarm_resource_1*, I stopped Akonadi, looked in ~/.config/akonadi and
found the file *agent_config_akonadi_kalarm_resource_1_changes.dat*, renamed
it, restarted Akonadi, and that seemed to fix it - the terminal output wasn't
looping, and HD light wasn't blinking. However, after a restart, it was back to
that behaviour, and while that "fix" worked again, since then it doesn't.

Looking online I found mention of deleting ~/.local/share/akonadi/mysql.conf
being a fix - that worked once, but after a reboot that did nothing - back to
constant disk access.

While looking in ~/.local/share/ I noticed 2 folders next to the *akonadi* one
- *akonadi_kalarm_resource_1* and *akonadi_kalarm_resource_5* - both containing
just under 350,000 files (Properties showing each took up 1.6Gb/2.9Gb on disk).
Since I could not open either folder due to the amount of files, running *dir*
revealed many thousands of files all with names like *expired.ics-99500*
numbered sequentially.

After quitting Kalarm I deleted those folders (I'm now in the middle of a 2h40m
process to delete the 699,000 files!), restarted Kalarm, and both those folders
were recreated, and immediately 4.7k files started being created in each, named
*expired.ics-1* upwards (it took only a few seconds for it to create 25 files).
So the hard-drive activity was a constant creation of files, simultaneously in
both those folders, which is endless if Akonadi is running. And that is needed
for Kalarm to function.

Since neither fix worked any more, I installed *akonadiconsole* to see if that
could help. Indeed Akonadi Console revealed that *akonadi_kalarm_resource_1* is
"kalarm" and that *akonadi_kalarm_resource_5* is "Archived Alarms". While
"kalarm" showed *Ready*, with *Type: KAlarm Directory* and *Status: Online,
Idle*, "Archived Alarms" (*Type: KAlarm Calendar File*) was constantly moving
from *Ready* to another state (it was too quick to see, but I think it
mentioned "synchronising"). Right-clicking that agent I saw I could "Abort
Activity", but thought I would try "Restart Agent", and that worked - "Archived
Alarms" now sits quietly on *Ready*, disk activity has stopped, and I can
confirm the files are no longer being created in either folder.

Obviously this is going to start all over again after a reboot, and while I am
hoping Akonadi Console can at least help me stop this, it's obvious this is a
pretty serious bug that needs to be ironed out. And I hope the above info is
enough - if not, let me know what info I can supply. And if anyone knows how to
actually FIX this once and for all, that info would be most welcome!

PS: In the "Component Description" on this page I see "Bugs which apply only to
the Akonadi version of KAlarm". As far as I can see, Kalarm NEEDS Akonadi, but
if there is actually a version which doesn't, then please direct me to it! I
don't use Kmail or any other Akonadi app, only Kalarm, so would prefer to use a
version that doesn't need Akonadi.
***


STEPS TO REPRODUCE
1. Restart system or Kalarm and it is back to this behaviour.

OBSERVED RESULT
Endless creation of files named expired.ics-XXXX in folders ~/.local/share/
akonadi_kalarm_resource_1 and ~/.local/share/ akonadi_kalarm_resource_5 (4.7k
files created every second or two in both folders simultaneously)

EXPECTED RESULT
Kalarm sits idle until needed, not create files every second or two in an
endless loop

Linux/KDE Plasma: Kubuntu 20.04
KDE Plasma Version: 5.18.8
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-120-generic
Kalarm Version: 2.13.3 (KDE Apps 19.12.3)

ADDITIONAL INFORMATION
* As far as I know, this behaviour wasn't happening until very recently (I am
quick to notice things like my HD light flickering for no reason I can think
of) - possibly after a recent system update.
* Kalarm works just fine after either fix which stops it writing to disk
incessantly. After choosing Restart Agent in Akonadi Console it is behaving,
and test alarms are popping up.
* I would consider upgrading Kalarm to the latest version (which may or may not
fix this behaviour) but can't find a repo or any way to do it.
* I would definitely consider using a version of Kalarm that is not dependent
on Akonadi - but while in a forum post the author mentions there is one, the
link to his downloads page is long dead.

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

Reply via email to