How to set the boot order for snaps after reboot?

hi all,
i want to know how to set the boot order for snaps after reboot?
such as i have install three snap(init, ros, pangda-hello) in ubuntu core system. how to configure the start sequence?(example: init snap start first then start ros snap, finally start pangda-hello snap)


There is no way for a snap developer to specify start up order of daemons packaged in different snaps.

If the three daemons are always intended to be used together, then perhaps packaging them as a single snap is the best option. You can then use the before: and after: keys on the daemons to impose ordering.

If you want looser coupling, another option is to keep the daemons in separate packages and use socket activation. This basically means that the systemd will create the listening sockets for your network services before trying to start any daemons, and pass those sockets in when it spawns them. This allows daemons to start in parallel but block when they try to talk to another service that isn’t yet ready. This removes the need for many explicit ordering constraints.

Thanks reply.

Could you give me a example for how to use before: and after: keys ?

And if i want use socket activation, What needs to be done for systemd and my app snaps to ordering?

Could you tell me some detail for using activation?

It seems to be missing from the docs, but it should look something like this:

(it isn’t restricted to notify-type daemons: that’s just what this particular test snap is using)

On the snapcraft.yaml side, you add a sockets section to your app and specify the socket name via the listen-stream key as described in the docs:

On the application side, rather than creating the listening socket via connect/bind/listen system calls, use sd_listen_fds() (or whatever equivalent API is available in the language the daemon is written in) to adopt the socket systemd has opened for you.

Here’s a trivial socket activated web app I wrote for a talk I gave earlier in the year as a full example:

It’s written in Go, but it should give you an idea of how everything hooks together.

note that in ubuntu core, while you can not influence the start order of different snaps after first boot, you can define the order in which the snaps get initialized during first boot … snapd processes the snap installation in the order the snaps are listed in the required-snaps field in your model assertion … so if you only require them to be in order in a first boot scenario, this is actually possible …

later on the snaps start in whatever order systemd finds is appropriate though.

thanks @jamesh
as you say for using the socket activation, i don’t see the two app snaps startup ordering, i only see between the webapp with systemd. not the webapp with another app to control the webapp snap is startup before another app snap.

I think you might have some misconceptions about how systemd starts daemons: absent any other ordering constraints, systemd will try to start multiple services simultaneously. It won’t necessarily wait for one service to finish starting before starting a second service.

Let’s take a concrete example of a database daemon, and a web daemon that stores its configuration in a database. In a traditional init system, you’d want to impose an ordering constraint so the database daemon is always started before the web daemon. If we instead use systemd and the database server supports socket activation, then it doesn’t matter what order the two daemons are started. There two possibilities:

  1. The database daemon starts first, and web daemon starts second. The web can talk to the database as normal.
  2. The web daemon starts first and blocks when it tries to connect to the database. Systemd notices the attempt to connect to the socket and starts the database daemon. The web daemon continues running once the database daemon has finished initialising and accepts the connection.

As you can see from case (2), systemd could even try to start both daemons simultaneously. It’s the act of communication that synchronises the start up of the two daemons rather than metadata in the .service files.