Snap service start ordering

#6

First part of the work updating YAML and app validation:

#7

@mborzecki I’ve moved the messages into this topic as it covers exactly that same aspect. There are also some related points in this other topic that is relevant here.

About the proposal and the implementation, it sounds better to name these as simply after and before, without the start- prefix, so they are implying an order without implying the fact starting the services is being requested. Otherwise it gets pretty confusing because you can order one service after two others, but that doesn’t imply starting it with these services, and once we introduce the fields starts-with and runs-with, it will get even more confusing.

#8

@cratliff this topic may be of interest to you.

#9

Sounds good to me. I’ll update the PR to reflect this on Monday.

#10

I’ve updated https://github.com/snapcore/snapd/pull/4340. With these changes, the snap YAML will look like this:

name: wat
version: 42
apps:
 foo:
   daemon: forking
   after:
     - bar
     - zed
 bar:
   daemon: forking
   before: [foo]
 baz:
   daemon: forking
   after: [foo]
 zed:
   ...
#11

Pushed the 2nd part of changes that updates how *.service files are generated

The snapd roadmap
#12

stating the obvious but this will need snapcraft work as well to accept the syntax there

#13

Thanks, good to know. This could do a lot to simplify how we are managing our services. There was a good list of other features though, like ‘with’ to be able to say to start with another service or event, but this is a good start. I should have done a better job at pushing that thread along. I’ll have to go review it to refresh my memory. I think we the main problem we had was nomenclature over the service features.

#14

FYI, the snapd changes have all landed in the master now.

#15

Hi,
Should this also order services startup on install?
It does not seem to work that way.
I have this snap file (https://github.com/syncloud/rocketchat/blob/master/snap/snap.yaml) and try to start rocket chat before mongodb, but startup order seem to be random.

#16

@ribalkin is it possible to get that snap somewhere?

#17

Build server does not publish it because install test is not passing but if you want I can publish snap.
I have few logs of that test like syslog:
http://artifact.syncloud.org/rocketchat/ci/205-snapd-amd64/rocketcaht_log/syslog.log

One thing to note I am using a bit modified snapd to test some improvements like systemd start timeout and also custom store backend.

I will publish snap soon and post a URL here.

#18

Here is the snap: apps.syncloud.org/apps/rocketchat_180201_amd64.snap

#19

Looks like the snap requires a ‘platform’ snap to be installed as well. Is this something you can upload as well?

#20

@ribalkin can you verify this please:

  • snap version is 2.31, rc1 or rc2 (don’t think there’s any other way of getting 2.31 atm other than --edge or --beta of core snap)
  • systemctl list-dependencies --before snap.rocketchat.server should list snap.rocketchat.nginx
  • systemctl list-dependencies --after snap.rocketchat.server should list snap.rocketchat.mongodb

Note that the after ordering does not imply systemd Requires, but rather it’s mapped to After. Similarly before is mapped to Before. Just for the record, even if a service is started, this does not imply that it’s usable in the sense that it’s actively listening on a port and accepting connections or somesuch.

If that ends up being too confusing I think it’s fair to consider an implied Requires in services that have after.

#21

I have rebased snapd on top of relese-2.31 branch which was at this commit(https://github.com/syncloud/snapd/commit/821c1e9a923217686b2a2f8b03b68cc5471cb772)
https://github.com/syncloud/snapd

Also you right about Requires, in non snapd mode I am using After and Requires and that work fine.
Forgot to say that I am adding snapd support to an existing installation procedure which works fine in this case so I have working systemd files (https://github.com/syncloud/rocketchat/tree/master/config/systemd)

You also right about start does not make service usable, but for that I have post start systemd commands and they actually wait for ports to open (I have added this to snapd fork).

Ideally I would like snapd to start my services on install in the exact order they are listed in yaml, but if before/after logic can reorder them properly I am fine with that, it just does not seem to do that.

#22

Right, that would definitely be nice. I’ll see what I can do.

#23

Please read this thread from the top again. We already discussed this to some length, and there’s design and rationale in place already (discussion welcome as usual). We can’t take order of declaration as meaningful for several reasons.

#24

Did not see the question about platform snap, yes it is here: apps.syncloud.org/apps/platform_180124_amd64.snap

#25

Should before/after drive services startup order on install or not?