Use of "before" and "after" keywords to define the start order of snap daemons

snapcraft
1

I’m trying to find a way to start the daemons in my snap in a given order. What I’m trying to achieve is that the daemons are started in the correct order when restarted (snap restart <mysnap>).

I’ve modified my snapcraft.yaml with “before” and “after” keywords in the app stanza, but I’ve not succeeded to change the order, it seems that “before” and “after” are simply ignored.

I’ve also noticed that “before” and “after” keywords are documented in https://snapcraft.io/docs/snap-format, but they are not documented in the Snapcraft app and service metadata page of the documentation (https://snapcraft.io/docs/snapcraft-app-and-service-metadata).

Are “before” and “after” the right way to obtain the described behavior? Any better way to suggest?

2

Yes, there is a bug that snap restart ignores the ordering of daemons. See https://bugs.launchpad.net/snapd/+bug/1803212

1 Like
3

The snap start looks at the order though and should follow before/after specified in snap(craft).yaml. You can try running snap stop <snap> && snap start <snap> in place of restart.

4

thanks. Anyway not sure it refers to my issue, it seems to be related to start of disabled services…

5

It does not work as well. To re-create the issue:

git clone https://github.com/dbruno74/test-apps.git
cd tests-apps.git
snapcraft --destructive-mode
snap install test-apps_0.1_amd64.snap --dangerous

Look at snap/snapcraft.yaml and notice the “after” keyword. Relevant code here:

apps:
  test-apps:
    command: test-apps.sh
  hello:
    command: hello.sh
  adaemon:
    command: adaemon.sh
    daemon: simple
    after:
      - oneshotdaemon
  oneshotdaemon:
    command: oneshotdaemon.sh
    daemon: oneshot

Then open a second terminal and start snap log

snap logs test-apps -f

In the first terminal stop and restart:

snap stop test-apps && snap start test-apps

Printouts on the second terminal:

2020-11-12T12:38:40Z test-apps.adaemon[273030]: adaemon is running
2020-11-12T12:38:43Z test-apps.adaemon[273030]: adaemon is running
2020-11-12T12:38:44Z systemd[1]: Stopping Service for snap application test-apps.adaemon...
2020-11-12T12:38:44Z systemd[1]: snap.test-apps.adaemon.service: Succeeded.
2020-11-12T12:38:44Z systemd[1]: Stopped Service for snap application test-apps.adaemon.
2020-11-12T12:38:44Z systemd[1]: Started Service for snap application test-apps.adaemon.
2020-11-12T12:38:44Z systemd[1]: Starting Service for snap application test-apps.oneshotdaemon...
2020-11-12T12:38:44Z test-apps.adaemon[273434]: adaemon is running
2020-11-12T12:38:44Z test-apps.oneshotdaemon[273435]: oneshotdaemon ran
2020-11-12T12:38:44Z systemd[1]: snap.test-apps.oneshotdaemon.service: Succeeded.
2020-11-12T12:38:44Z systemd[1]: Finished Service for snap application test-apps.oneshotdaemon.
2020-11-12T12:38:47Z test-apps.adaemon[273434]: adaemon is running
2020-11-12T12:38:50Z test-apps.adaemon[273434]: adaemon is running

As you can see, adaemon is always started first.

6

Can you attach the output of the following command?

systemctl show snap.test-apps.\* | \
   grep -e ExecMainStartTimestamp -e 'ControlGroup='
7 
dbruno74@dbruno74-XPS-13-9300:~$ systemctl show snap.test-apps.\* | \
>    grep -e ExecMainStartTimestamp -e 'ControlGroup='
ExecMainStartTimestamp=Thu 2020-11-12 13:38:44 CET
ExecMainStartTimestampMonotonic=104297358629
ControlGroup=/system.slice/snap.test-apps.adaemon.service
8

Thanks. It is a bug I though was fixed long ago. There is an open PR however, which afaict should address it and make at least the workaround do the right thing.

Edit: Just for the record, the ordering is preserved at install time.

2 Likes
9

https://github.com/snapcore/snapd/pull/8960 (which has been in a review for a while and is a large overhaul of service-related code in snapd) fixes stop/start order.

I’ve just proposed a followup - https://github.com/snapcore/snapd/pull/9641 - which fixes it for snap restart ... and improves associated spread test for ensure-before ordering.

2 Likes