Re: Smooth upgrades for socket activated services

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Do, 02.03.23 23:05, Mike Hearn (mike@hydraulic.software) wrote:

> > There's currently no mechanism for that. File an RFE issue.
>
> https://github.com/systemd/systemd/issues/26647
>
> > In the "Portable Services" concept we currently assume you update the
> > disk image ("DDI") the service is on, and then simply restart the
> > service while leaving the socket around.
>
> I've always wanted to understand portable services better. I never
> quite grokked if portable services were meant for apps or operating
> system level stuff, or if it didn't matter.

Not sure what you mean by "apps"? desktop apps? They are conceptually
suitable for that, but not realistically, since we currently require
privs to mount disk images, and thus the whole concept is simply not
available for unpriv code.

So the focus is system-level services or system-level
"apps". i.e. stuff that might or might not have privs, stuff that
could use DynamicUser=1 (though this is not a requirement) and similar.

> It also wasn't quite clear
> to me how upgrades worked for them either - presumably if you stick
> them inside a deb or rpm you have the same problem, or if you rsync up
> a new image, etc. It'd be great to have some blog posts that tackle
> portable services end-to-end from the perspective of running
> servers.

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 (well,
unless you make changes to the service definitions, in that case you
need to issue "portablectl reattach").

if tools update files like that then the old version of the portable
services can use the old image as long as it wants, and only once the
last reference to it is dropped it disappears from memory on disk. At
the same time the new invocatoin will only use the new disk image.

> > 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.

Lennart

--
Lennart Poettering, Berlin



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux