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.
From version 3.0 (KDE Apps 20.08), KAlarm no longer uses Akonadi, which fixes this issue. The decision to stop using Akonadi was due to the number of problems which kept arising with Akonadi - your issue is just one example of this, unfortunately. I'm not aware of any way of upgrading KAlarm by itself, so in order to KAlarm version 3 or later, you would probably have to upgrade KDE as a whole, which is likely to require a distro upgrade. You may be able to partially fix your problem with your current version as follows: 1) In the KAlarm main window, display the Calendars panel (using View -> Show Calendars) and select the calendar type of Archived Alarms. Hover over the listed resource (which will probably be called "Archived Alarms" to find out its file location, and note the location for later. 2) Ensure that no KAlarm alarm messages are currently displayed, and stop KAlarm by File -> Quit. (Or kill kalarm from the command line.) 3) Run akonadiconsole. In the Agents tab, select KAlarm's Archived Alarms, and remove it. 4) Run KAlarm again. It should recreate the archived alarms resource - check that it has done so by again looking at the archived alarms in the Calendars panel. A single calendar "Archived Alarms" should be listed (as before). If not, click Add and enter the noted file location, select alarm type Archived Alarms, and give it the display name "Archived Alarms". 5) Check whether this has improved the CPU consumption for the akaondi_kalarm_resource_* processes. I'm not sure whether creating a new KAlarm Directory resource works, so if you try to do the same for the Active Alarms calendar, you might possibly be unable to access your active alarms afterwards. You may just have to live with the problem until you are able to update to KAlarm version 3.
(In reply to David Jarvie from comment #1) Hi David - many thanks, and sorry I didn't notice I'd gotten a reply 'til now! Thanks for all that info - while it's a pity there doesn't seem to be a way to upgrade Kalarm (which would be understandable if it needed a newer version of Akonadi, which it doesn't, so it's a bit perplexing), it's good to know that when I upgrade the system, this will be a thing of the past. And many thanks for your workaround - while it has been behaving ever since I fiddled around in Akonadi Console, so installing that app was definitely worth it, I'll keep your workaround in case I ever need it! Oh, and I actually put some wrong info in my summary, and apparently users can't edit their own comments on this site. I was incorrect when I said: *akonadi_kalarm_resource_1* is "kalarm" and that *akonadi_kalarm_resource_5* is "Archived Alarms" Both of those are actually "Archived Alarms" - "kalarm" is *akonadi_kalarm_dir_resource_1* - but it was only *akonadi_kalarm_resource_5* that was going back and forth from Ready to being busy. And I'm happy to note that after choosing to "Restart Agent", the problem hasn't restarted after multiple reboots! Cheers, and thanks for your input.
I'm glad you've been able to solve your problems by using the workaround. Re-setting the bug status to fixed, since it's fixed in later versions.
(In reply to David Jarvie from comment #3) > I'm glad you've been able to solve your problems by using the workaround. > > Re-setting the bug status to fixed, since it's fixed in later versions. Hi again. OK, I bit the bullet, and have upgraded to 22.04 as suggested - however, now KAlarm fails to load at all! I first noticed there was no tray icon for it after the first boot, and when I've tried to launch it via Application Launcher, it's button shows up in the taskbar, with the moving circle indicating it is loading, but then the button disappears, and no KAlarm. When I try initiating it via the terminal, all I get is a frozen cursor beneath it, no output whatsoever. Looking at htop, I see *kalarm --tray* is apparently running. I downloaded the version for 22.04 - which I couldn't help but notice the page says it depends on the package akonadi-server, which I thought it no longer does - but when running the .deb I am told I already have the same version installed, and reinstalling it does not fix this. Any ideas on what is going on, and how I can fix this? I really (URGENTLY!) need KAlarm to be working. Many thanks in advance!
I have suspected in the past that sometimes KAlarm does not show up in the system tray when it should. I suspect that this may have been due to some glitch in Plasma, although I could never confirm this. In KDE 22.08, I haven't seen this issue, so it may have been fixed by now. I suggest that if KAlarm is running, i.e. if 'kalarm --tray' shows in the task list, that you kill it, and then start up KAlarm again. Then in its Preferences dialog (Settings -> Configure KAlarm), in the View tab, deselect Show in System Tray. It should then run normally but not in the system tray.