[systemd-devel] Smooth upgrades for socket activated services

[Luca Boccassi]

On Fri, 3 Mar 2023 at 09:17, Mike Hearn <mike at hydraulic.software> wrote:
> > > > But of course such an approach requires that services are written in a
> > > > way this is possible
> > >
> > > Right. I think that'd be quite hard to do especially with servers
> > > written in portable languages that don't expose stuff unavailable on
> > > Windows e.g. the JVM.
> >
> > Why would that be? portable services are just regular services that
> > happen to come with their own disk images, that's all.
>
> Sorry I meant the serialization and transmission of FDs to the fd
> store to support user-transparent restart. For example the Java API
> has no way to send fds over a UNIX domain socket because Windows
> doesn't support that, so you need third party libraries. And then it
> would appear to turn into a general problem of serializing the entire
> state of the app which is quite hard. Easier to assume that one
> connection should stick with one server version for the lifetime of
> that connection and then just phase in new servers as new connections
> roll in.

It only sounds easier, because it postpones the difficult part for
later. It requires every service to behave perfectly well and
according to the specification, and delegates process management down
to them. Except services cannot be relied upon, and will get it wrong,
and that will cause multiple versions of the same service to exist at
the same time and conflict with each other, and require manual
intervention to fix. On a "pet" machine (ie: your laptop) it's fixable
busywork, on a system with tens of thousands of headless nodes not
much so.

It is not a reliable and trustworthy pattern. The advantage of moving
state across via FD is not only speed and memory (double amount of
services, double amount of memory/cpu consumed and double hard cap of
memory needed on the system), but it's mainly about reliability by not
having to delegate process management to clients. Ie: when systemd
tells you to stop, you stop, end of story.