Incomplete documentation on oneshot daemons

snapcraft
1

Hey there,

Nothing urgent, but I think the documentation here is rather limited with respect to the daemon options.

I would say the information on the “oneshot” type is incomplete; all it mentions is that “Run once and exit after completion, notifying systemd. After completion, the daemon is still considered active and running .” However, from my own experience there are several details that are important when deciding what daemon type to use:

  • If the oneshot daemon fails, the installation of the snap fails (source: from own experience)
  • For the snap installation to complete, the daemon has to complete (source: this post)

The latter means for example, that if there is any dependencies on interfaces, it is impossible to install a snap unless the interfaces are connected automatically by snapd. In addition, I guess it means you have to make execution rather short if you want to use oneshot daemons.

On the other hand, this is interesting functionality when you want to be able to fail updates if certain conditions are not met, another reason to document it.

Maybe this information is common knowledge when familiar with systemd, but it wasn’t for me :slight_smile:

2

This is true for all daemons (as it is for broken hooks too, if any step of setting up the snap at install/upgrade time fails it rolls back to the former state… (For install that means uninstall, else it goes to the former revision))

3

I know it is the case for hooks, but I tested it with a “simple” daemon and raising an exception does not fail the install.

Which sort of makes sense, because since the “simple” daemon runs forever, how does systemd knows how long to wait until deciding the installation is complete?

I tested it with

  dbus-interface-service:
    daemon: simple
    install-mode: enable
    command: dbus-interface/main.py

With main.py

#!/usr/bin/env python3

raise RuntimeError("Test failure")

This installs with no issues, just tries to run the daemon a few times and then gives up.

Is there a way to cause this to fail installation?

4

Hmm, have you tried to just put garbage into it to produce a syntax error? I would normally expect the above to make it fail but probably the python interpreter somehow stays alive with raise (systemd likely just watches the interpreter) ?

5

For a bash script like this:

#!/bin/bash

echo "Fail on purpose"
exit -1

Installation also succeeds, same result, fails a few times resulting in the status of the service to be disabled, inactive

6

But I also think if a daemon dying would fail the installation, it would make sense to define the time it should be alive in the documentation.

If it would fail after 24h of running, I assume it is not desired behavior for the system to roll back.

Ideally it would be configurable :smiley: