Automatically shutting down a daemon on inactivity

tl;dr: Use gss_service_hold() and gss_service_release() from libgsystemservice.

Automatically shutting down daemons when not in use is in vogue, and a good way of saving resources quite easily (if the service’s startup/shutdown costs are low).

libgsystemservice can do this for you automatically, if your code is based on GssService, or if you want to port over to it (which should be fairly straightforward for simple services). It supports inactivity timeouts by default; just call gss_service_hold() when you start doing some activity, and gss_service_release() when you stop.

(Also, look, it’s neat that you can generate documentation and automatically publish it from your master branch using GitLab CI!)

4 thoughts on “Automatically shutting down a daemon on inactivity

    1. Philip Withnall Post author

      libgsystemservice is intended for the system bus, yes. It provides various things which don’t make sense on a session bus. Without knowing anything about the design for quit-and-stay-resident mode in Geary, I can’t confidently suggest the right approach, but from reading that wiki page I suspect it would be appropriate to extend `GtkApplication` to support this.

      It might make sense to extend libgsystemservice to support session daemons, but only ones which never show a window (i.e. they are designed as a daemon, not an app). If someone wants to open an issue about that (https://gitlab.gnome.org/pwithnall/libgsystemservice/issues), it could be discussed there.

      Reply
  1. alex

    I had the idea of a daemon which loads many tasks in form of shared libs and is controlled by dbus. This way writing daemons is straightforward (just writing a plugin) and saves a lot of memory (by unloading if the task is finished+no own daemon routines)
    Because there are not many context switches (no signals, no processes) in my proposed solution it would probably be much faster. But... no time.

    Reply
    1. Philip Withnall Post author

      You need separation between processes to get isolation of the security domains of the different tasks. Your idea would only work if all the tasks could be mutually trusted to access each others’ data.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.