First part of the work updating YAML and app validation:
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.
@cratliff this topic may be of interest to you.
Sounds good to me. I’ll update the PR to reflect this on Monday.
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: ...
Pushed the 2nd part of changes that updates how
*.service files are generated
stating the obvious but this will need snapcraft work as well to accept the syntax there
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.
FYI, the snapd changes have all landed in the master now.
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.
@ribalkin is it possible to get that snap somewhere?
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:
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.
Here is the snap: apps.syncloud.org/apps/rocketchat_180201_amd64.snap
Looks like the snap requires a ‘platform’ snap to be installed as well. Is this something you can upload as well?
@ribalkin can you verify this please:
snap versionis 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.servershould list
systemctl list-dependencies --after snap.rocketchat.servershould list
Note that the
after ordering does not imply systemd
Requires, but rather it’s mapped to
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
I have rebased snapd on top of relese-2.31 branch which was at this commit(https://github.com/syncloud/snapd/commit/821c1e9a923217686b2a2f8b03b68cc5471cb772)
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.
Right, that would definitely be nice. I’ll see what I can do.
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.
Did not see the question about platform snap, yes it is here: apps.syncloud.org/apps/platform_180124_amd64.snap
Should before/after drive services startup order on install or not?