<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word"> <div class="WordSection1"> Thank for this.<o:p></o:p> We tested the move_mount syscall with the MOVE_MOUNT_BENEATH flag and found that it only works if the parent mount is set to private, which is related to how mount propagation works. This means it would only be usable on systems where the root filesystem is set to --make-private, or if we temporarily switch to a private state, perform the system-sysext operations, and then switch back to shared.<o:p></o:p> We are not experts on the details of the VFS, but would this temporary switch to private affect mount spaces and make the updated system extensions invisible? Also, how would this approach impact portable services in systemd? Could it cause any issues with how portable service images are accessed or made visible, especially if they depend on shared mount propagation?<o:p></o:p> <o:p> </o:p> Umut<o:p></o:p> <o:p> </o:p> <div id="mail-editor-reference-message-container"> <div> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: Lennart Poettering <lennart@poettering.net> Date: Thursday, 28 November 2024 at 09:49 To: Umut Tezduyar Lindskog <Umut.Tezduyar@axis.com> Cc: systemd-devel@lists.freedesktop.org <systemd-devel@lists.freedesktop.org> Subject: Re: [systemd-devel] detaching existing extensions with new systemd extension attach<o:p></o:p> </div> <div> On Mi, 27.11.24 19:00, Umut Tezduyar Lindskog (Umut.Tezduyar@axis.com) wrote: > Hello systemd, > > We are looking into systemd system extensions for quick patching our > immutable images while we are updating and rolling out the patched > immutable image. > > One thing that is stated in the documentation is that before > attaching a new extension, all previous extensions are deattached > and everything are attached again. We understand that this sequence > is needed for overlayfs stacking in case something has changed in > the stack with the new extension. > > For our use case, we would like to be able to push multiple patch > extensions (ex: couple of days apart) while keeping the service > downtime to a minimum. Technically we believe that if the extensions > are not overlapping there is no need to detach already attached > extensions. There is no built in option in systemd extensions to > keep the existing extensions right? Due to how overlayfs works, they > temporarly need to be removed and thenbrought up again, during a > refresh operation. There's actually a kernel feature these days (MOVE_MOUNT_BENEATH) that allows us to atomically replace mounts. This is still not hooked up to systemd-sysext however, but we really should. With that we can add, remove, change sysexts during runtime with minimal impact: apps will only see the old set of sysexts or the new set of sysexts but never an intermediary state where the old sysexts are gone but the new ones not yet attached. > While on the topic, we have investigated other file systems. One we > put our attention to is mergerfs, which is a fuse file system to > allows "mount points" to be dynamically added/removed without doing > a mount/unmount. Is there support in systemd extensions to let > system extension work with other file systems than overlayfs? No, overlayfs is good enough and it is the only one that is in the kernel and hence efficient enough with acceptable semantics. All that other stuff is typically implemented in userspace with fuse and that's generally OK as a toy, but not really something we'd want to deploy. MOVE_MOUNT_BENEATH should be the ideal way out though. We just need someone to sit down a bit and actually make use of it. (Interestingly, the ExtensionImages= support in service units actually *does* suppport MOVE_MOUNT_BENEATH already, it's only the system-wide concept that doesn't. And we really should change that.) Lennart -- Lennart Poettering, Berlin<o:p></o:p> </div> </div> </div> </div> </div> </body> </html>