[fragmede]

You patch it in memory and on disk. What you put on disk is the patch though, so when you restart, the original unpatched version is booted, and then the same live patch is applied. This is how Ksplice worked. It has the advantage that there isn't a config file in /etc to get changed out from under it, so the second problem did not apply.

[da_chicken]

Ksplice can do that because the kernel is only in memory in one place an it never sleeps. It has to orchestrate a process that's always running, which is complex, but it's never more than one.

Now try patching glibc like that. Not only does almost every thread have it in memory, several of them will have it in process, and some of them will have it swapped to disk while the thread sleeps. You're going to quickly decide that you actually just want a little bit of downtime or else you want to stand up a redundant system. There's a reason that some live patching systems explicitly exclude glibc and similar libraries.

[fragmede]

The corporate named "Ksplice for userspace" did exactly that, patch glibc.

https://blogs.oracle.com/linux/new-userspace-patching-with-o...