Smooth upgrades for socket activated services

[Mike Hearn <mike@hydraulic.software>]

Hi,

I'm exploring socket activation as part of work on a tool that makes
systemd-controlled servers easier to deploy and use. Given a config
file the tool builds a package that contains the app and systemd
units, uploads it, installs it with dependency resolution, the
postinst scripts start the service etc. It's sort of a Docker
alternative that's more classically Linux-y, designed for a world
where really big machines are really cheap and thus many apps don't
need to be cattle-ized. Pets are sometimes OK.

As part of this I'm looking at how to make upgrades smooth. Socket
activation already allows you to shut down, upgrade and restart a
service without dropping connections because systemd will hold the
connections until the service comes back but there are a couple of
aspects that weren't really clear to me from reading the excellent
"pid eins" blog post series. Could we maybe get a new blog post
exploring these issues?

1. How exactly should you stop a service that's socket activated so it
won't be re-activated during the upgrade but new connections won't be
lost, e.g. in package scripts that are executed across upgrades.
Currently the scripts stop the service before the upgrade happens,
then restart afterwards.

2. Is it possible to run two versions of a service unit at once such
that the old version finishes handling connections and then shuts
down, whilst new connections are being handled by the new version?

I feel intuitively that this should be possible for services like ssh,
but you'd need it for anything that serves downloads. Obviously
services would have to opt in to this, as they'd have to be able to
handle two versions running at once in terms of shared
state/config/caches etc, but for servers that can handle this it would
make upgrades entirely transparent.

thanks,
-mike