Re: detaching existing extensions with new systemd extension attach

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 27.11.24 19:00, Umut Tezduyar Lindskog (Umut.Tezduyar@xxxxxxxx) 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