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