Bug 289342 - Akonadi server should shut down automatically if idle
Summary: Akonadi server should shut down automatically if idle
Status: CONFIRMED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 412240 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-19 09:48 UTC by Jonathan Marten
Modified: 2019-09-23 15:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Marten 2011-12-19 09:48:46 UTC
Version:           unspecified (using Devel) 
OS:                Linux

One the Akonadi server has been started by any PIM application, it continues to run even if all PIM applications are closed.  This not only uses system resources (which may be important on small devices), but also means that the PIM data continues to be accessed even if the user is not expecting it.

For example, a user may exit KMail in the expectation that they can go to another computer, or to a webmail system, and access any mail that subsequently arrives from there.  However, Akonadi will still continue to fetch POP3 mail in the background at the configured interval.

This also has implications for backup, Akonadi needs to be shut down to ensure that the state on disc is consistent but again exiting all PIM applications is not sufficient to do this.

The Akonadi server should be configurable with the option to shut down automatically if it is idle.  Obviously stopping and starting the server takes time, so there should be an idle time (e.g. 1 minute) so that this does not happen unnecessarily.


Reproducible: Always

Steps to Reproduce:
Start a PIM application, then exit it.


Actual Results:  
Observe that Akonadi continues to run.


Expected Results:  
See above.
Comment 1 Christophe Marin 2011-12-19 12:27:52 UTC
so, following your logic, you should also:
- stop cups when you don't need it,
- stop the firewall when you don't need it,
- stop udev when you don't need it 

and so on for every service ?
Comment 2 Jonathan Marten 2011-12-19 14:05:53 UTC
I don't think the comparison is quite fair.  Certainly the latter two of those that you mention provide essential system services that need to operate regardless of what the user is doing - or even when no user is logged in.  It could be argued that CUPS could stop when idle - but it needs to run as root in order to perform some of its functions and therefore there may be problems in starting/stopping it on user demand.

Akonadi, on the other hand, requires no privileges and provides access to the user's data (whether local or remote) at the user's request when using PIM applications (the Plasma calendar counts as one of those).  If the user is not using the application, there is no need for Akonadi to remain active, and there could even be data integrity problems if it continues to access the data or remote resources even when the user is not expecting it to.  In my example of continuing to access POP3 mail after KMail has exited, this could lead to emails being fetched and stored where the user is not expecting them to go - which is only a step away from data loss.

On the question of the system resources used by Akonadi this is surely not the first time that this has been raised, but just for illustration:

akonadi_control				1.0M
mysqld					46.1M
akonadiserver				3.4M
akonadi_agent_launcher			2.6M
akonadi_kdeaccounts_resource		9.3M
akonadi_agent_launcher			4.6M
akonadi_maildispatcher_agent		4.4M
akonadi_mailfilter_agent		5.7M
akonadi_pop3_resource			8.2M
akonadi_vcarddir_resource		3.0M

cupsd					912K

(Reported by KDE System Activity in the "Mem" column.  No PIM applications running, KMail configured for Local Folders + 1 POP3 fetch, KAddressBook with 2 resources, Nepomuk Email Indexer turned off.  So Akonadi is using nearly 100 times the memory of CUPS.)
Comment 3 Niels van Mourik 2012-06-05 10:41:18 UTC
Please be a bit more polite here, we are all trying to improve KDE and Akonadi to gain more market share.

I'm actually agreeing with Jonathan that this makes sense as we'd only like these services to be available when we - the user - demand them to. Let's not forget the user perspective in here, that doesn't know what "Akonadi" is and - as being a humble user - shouldn't know about it. Akonadi is a background service that facilitates the user indirectly and therefore should be gaining less to no direct attention - even not in unexpected system resources.

Adding a "auto shutdown" feature would be very appreciated - and I think I speak on behalf of many KDE users - and even does it when it's optional.

Niels
(In reply to comment #1)
> so, following your logic, you should also:
> - stop cups when you don't need it,
> - stop the firewall when you don't need it,
> - stop udev when you don't need it 
> 
> and so on for every service ?
Comment 4 Christophe Marin 2012-06-09 09:50:44 UTC
(In reply to comment #3)
> Please be a bit more polite here, we are all trying to improve KDE and
> Akonadi to gain more market share.

We'll survive without this kind of useless advices.

> 
> I'm actually agreeing with Jonathan that this makes sense as we'd only like
> these services to be available when we - the user - demand them to. 

Thanks, that's *exactly* why the resources and consequently the Akonadi server are not stopped: to be available when the user needs them.

> Let's
> not forget the user perspective in here, that doesn't know what "Akonadi" is
> and - as being a humble user - shouldn't know about it. Akonadi is a
> background service that facilitates the user indirectly and therefore should
> be gaining less to no direct attention - even not in unexpected system
> resources.

Unrelated

> Adding a "auto shutdown" feature would be very appreciated - and I think I
> speak on behalf of many KDE users - and even does it when it's optional.
> 
No, you speak on *your* behalf
Comment 5 xor 2012-11-19 00:12:40 UTC
I'm voting for this.
Comment 6 Christophe Marin 2019-09-23 15:52:06 UTC
*** Bug 412240 has been marked as a duplicate of this bug. ***