Snap service start ordering

snapd
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?

26

Yes, and I think we have a bug about this that @mborzecki raised this morning. Today weā€™re starting up services manually, and doing so one-by-one. We need to fix the logic so they are all started together by snapd, which means systemd will have a chance to enforce the stated order.

That said, note that this wonā€™t force the startup of services if one of them is disabled. In other words, after/before only affect ordering, but not the actual dependency between services. Thatā€™s what I was mentioning to @mborzecki above.

27

JFYI

After fixing start-timeout and listing services in the order they should start in snap.yaml everything worked.

Interesting thing that the generated systemd files showed After/Before for my other services in them (this a good thing):

services.go:178: Systemd file for snap.rocketchat.server.service: 
[Unit] # Auto-generated, DO NOT EDIT
Description=Service for snap application rocketchat.server
Requires=snap-rocketchat-x1.mount 
Wants=network-online.target
After=snap-rocketchat-x1.mount network-online.target snap.rocketchat.mongodb.service 
X-Snappy=yes
[Service]
ExecStart=/usr/bin/snap run rocketchat.server
SyslogIdentifier=rocketchat.server
Restart=always
WorkingDirectory=/var/snap/rocketchat/x1
ExecStartPost=/usr/bin/snap run --command=post-start rocketchat.server
TimeoutStartSec=600
TimeoutStopSec=30
Type=simple
[Install]
WantedBy=multi-user.target

After changing the order in snap.yaml to see if before/after corrects it, real order was incorrect and services did not start properly.

28

Yes, this is generated based on the after, before properties of apps in snap.yaml

Note that the order in which the apps are traversed when starting is not stable. Iā€™ve opened a PR to start all services from one snap in a single systemctl call https://github.com/snapcore/snapd/pull/4594. Hopefully this will do the trick and systemd will be able to do its thing.

29

Looks like this PR is merged, is there any release branch I can use to test it?

30

Iā€™m afraid itā€™s only in the master branch at this point. Unfortunately it was overlooked for 2.31.1 release. If you are doing builds yourself you can try cherry-picking the patches. Otherwise the changes should also be in the core from edge.

31

Is it relatively safe to use master?
This is for testing only, but I do not want to spend days on something non related.
Otherwise I can cherry pick it as you said.

32

Iā€™m running the ā€˜masterā€™ builds on my Arch development box and itā€™s mostly issue free (with the exception of the need to use core from edge occasionally), but YMMV and cherry-picking is probably an easy way out.