Re: Smooth upgrades for socket activated services

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 03.03.23 10:16, Mike Hearn (mike@hydraulic.software) wrote:

> Sorry, by "apps" I meant anything not supplied by OS developers. In
> this context, servers e.g. custom web app servers. I do currently run
> some of those with DynamicUser=1 and similar.
>
> > As long as the tool updating the disk image creates the new one under
> > a temporary name, and then replaces the old one with it via renaming,
> > upgrading portable services is as easy as restarting them
>
> Great.
>
> > > > 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.

Right, writing system services in Java is indeed a headache I am
sure. No ready notifications, no socket activation, no fdstore, no
signals, no dbus, no watchdog logic, …

it's a race to the bottom if you never want to make use of the *good*
stuff. But then you shouldn't be surprised if you can't do certain
things...

Lennart

--
Lennart Poettering, Berlin