Does anyone use kernel live patcing in Arch?

General system Kernel, boot, graphics & hardware
1

I have been looking at the following ArchWiki article:

https://wiki.archlinux.org/title/Kernel_live_patching

I am not sure if I correctly understand it. Is it only for when you patch the kernel manually yourself or can it be configured to eliminate the rebooting whenever you get an update to your running kernel through pacman?

1 Like
2

I have never used it but here is my (limited) understanding.

  • It isn’t for upgrading kernels, it is for applying small focused patches to running kernels such as security patches.
  • To use it on Arch you would have to build your own kernels and have a kernel with that support loaded. You could then patch and rebuild the kernel to apply a patch to the kernel while it was running.

I am not sure I see a practical use case for this on a typical desktop usage scenario. It seems like it would be much more work than rebooting would be.

3 Likes
3

Thanks for the reply!

This is what I think I understood reading that article.

It certainly looks like so! :sweat_smile:

I might be mistaken but doesn’t Ubuntu supports such a feature for “in-place” kernel upgrades? I thought perhaps something similar could be implemented in Arch.

Perhaps it is more suitable for servers? But then one might ask if Arch is suitable for servers or not.

1 Like
4

Canonical livepatch.

Definitely. The obvious use case is something that is both critical enough that it can’t be safely rebooted and also that the specific security patch is urgent enough that you would risk live-patching it.

It would be a good question. My opinion, as someone who stopped running servers on Arch is that for most server use cases, Arch isn’t worth the hassle.

Things that can happen to Arch servers over a long period of time:

  • Development tools get updated in a why that breaks a running application.
  • Server software makes non-backwards compatible config file changes that break a running application.
  • A library that your application needs get updated and breaks the application.
  • A server application gets a new major release and since Arch gets it at the x.0 state, you end with something running that has bugs.

The safest way to use Arch as a server is by isolating everything in non-Arch stable containers of some sort. However, if you do that, what is the advantage of running Arch in the first place?

Of course, some things will run fine, potentially for years. About at the time you think you are safe, they break. The whole, “I have never had an issue” saying should be rewritten as “I haven’t had an issue yet but I probably will in the future, I just don’t know it yet” :rofl:

5 Likes
5

:rofl:

So to summarize (sort of): “Don’t use Arch for servers!”
It’s not a question of if it will break but when it will.

Question asked and answered.
Thank you so much @dalto for sharing your insight!

Marking it solved.

2 Likes
6

Great motto! :laughing:

NO ONE IS SAFE!!! :alien:

4 Likes
7

Given that the statement “Arch is not for servers” has general applicability, it remains true that for certain servers it can achieve usability. The trick I use is to remain a week behind or so at all times, leaving a gap between current updates and their issues being cured. So far my mirrors have experienced only a couple of minutes total of ‘downtime’ while rebooting after updates of kernels - but how critical mirror serving is can be debated!

2 Likes
8

That will do very little to help most issues with server use cases.

1 Like
9

Which is why I prefaced it with agreement that Arch-based is generally not for server use. There do exist more non-critical uses, however, which can be kept going as described above.

Think of it as a methodology for those who can’t get comfortable with more server-centric distros any more :grin:

10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.