Comment 9 for bug 1803212

I just tested this with the edgexfoundry snap and it looks like the behavior with respect to "enabled/inactive" services is what was originally proposed in the forum post (i.e. these services are not started), not was was suggested by Ian in his response to the post, and in comment #6.

In the case of the edgexfoundry snap, this results in the services being in a non-functioning state, as the -setup services (which are all "enabled/inactive", of type "oneshot") are not started.

I verified this by grabbing all the systemd "Starting/Stopping Service..." messages in the journal after the restart was issued.

Also the 'snap tasks' output erroneously still lists all of the services as being restarted:

$ snap tasks 272
Status Spawn Ready Summary
Done today at 12:57 EDT today at 12:57 EDT Run service command "restart" for services ["app-service-configurable" "consul" "core-command" "core-data" "core-metadata" "device-virtual" "kong-daemon" "kuiper" "postgres" "redis" "security-bootstrap-redis" "security-proxy-setup" "security-secrets-setup" "security-secretstore-setup" "support-notifications" "support-scheduler" "sys-mgmt-agent" "vault"] of snap "edgexfoundry"

Note, this behavior also doesn't match the behavior of a reboot...

Tested with edgexfoundry snap (amd64/3066) and snapd 2.52 (13270) on Ubuntu 20.04.