MeeGo 1.2 Harmattan Developer Documentation Develop for the Nokia N9

Creating daemons

Daemons, also known as background applications or services, are applications that are launched at device startup and do not feature a UI or require other direct user input. They perform a defined operation and are usually launched at predefined times or in response to events on the device. Common usages for daemons include e-mail handler applications and monitoring tools, among others.

However, Daemons are a specialized type of application, and in general you do not need to concern yourself with daemon development.

Daemons and power consumption

Any software that is running regularly or all the time is potentially risky for the device battery lifetime. Therefore, when implementing daemons, power saving must be taken into account with special care. For a general discussion on saving power, see Optimising power consumption.

Before you start designing a daemon, take the following considerations into account:

  • Is a daemon necessary at all?
    Consider carefully if your application requires a daemon or any background functionality at all. For example, if updates that the daemon does are only related to the content shown in the application UI, it may be enough to only perform the updates when the application UI is running and visible. A daemon should be used only when necessary.
  • Can the background functionality be handled with Synchronization Framework?
    Many applications that require some background functionality can be handled with the Synchronization Framework instead of creating a daemon. When you create a plugin for the SyncFW, it can be run in the background according to a predefined schedule. However, this process is not running constantly, which saves power. For an example on using Synchronization Framework, see Integrating event feed into applications.

If after these considerations, a daemon is still the best available solution, make sure you design it carefully in order not to drain the battery of the device. To accomplish that, try to follow these guidelines:

  • The daemon should preferably react to events rather than running on a timer or a schedule.
  • If you need to do periodic operations, use the System Heartbeat API instead of an exact timer.
  • Stop all network-related activities when the device is not connected to a network. For more information on the topic, see Optimising power consumption.

Creating daemons

On Harmattan devices, the configuration files of third party daemons must be placed into the /etc/init/apps/ directory when they are installed on the device. At the end of the device boot sequence, the Upstart framework executes applications within that directory. Note that the boot sequence may last up to a minute even though the device main view is already loaded.

To install your files into the correct directory, add the following lines to your project file:

mydaemon.path = /etc/init/apps
mydaemon.files = <path/to/daemon_config_file>

INSTALLS += mydaemon

The contents of the config file should contain at least commands for starting, stopping and executing the daemon. Here is an example template for the config file.

# Example 3rd party application/daemon startup script.
# Install the startup script to /etc/init/apps
# Applications are started after official stuff is done.
# The name of the script has to be unique, suffix .conf is mandatory.
# Applications are started in alphabetical order; note that
# 3rd party applications are not run in malfunction state nor in
# charging/act-dead mode.
# Stanzas that are limited:
# oom (negative values)
# nice (negative values)
# reboot (not allowed)
# start on (not allowed)
# stop on (only "core_shutdown" and "stopping xsession" allowed)
# During installation, application can be  started by issuing command
# "start apps/myapp" in post-install script. Note that suffix .conf must
# be omitted.

# Description of the script, mandatory
description "Example startup script"

# Author e-mail address, mandatory
author "somebody@example.invalid"

# Start on stanza is ignored for 3rd party apps

# One and only one "stop on" is allowed (mandatory)
# If missing or invalid, it'll be forced to "stopping xsession"

# stop when xsession is stopped
stop on stopping xsession

# stop when device is shut down (keep running in charging/act-dead mode)
# stop on core_shutdown

# stdout to /dev/null, use "console output" to direct stdout to console (optional)
console none

# if application exits, restart it (optional)

# restart max 3 times withing 300 secs (optional, you need respawn defined)
respawn limit 3 300

# not a critical task (optional, negative nice not allowed)
nice 2

# do not restart if exitcode is 0 (optional)
# normal exit 0

# start the app (/usr/bin/myapp)
# (change the pathname of the exec, of course);
# If you need to do preparations, you can use normal Upstart stanzas
# such as pre-start, post-start, script, pre-stop and post-stop sections

# Start myapp as user
exec /usr/bin/aegis-exec -s -u user /opt/myapp/bin/myapp 

# Start myapp as root
# exec /opt/myapp/bin/myapp

Further information

For more information on creating daemons, see the following links: