Ubuntu Livepatch

I tried out Livepatch for a short time, but noticed that even when it did do kernel patches, the system still showed the old kernel was being used. Not sure if it’s working as intended or a bug?

I’m looking for opinions on anyone who has used Livepatch on Ubuntu.

Welcome to the forum!

I never used live patching, but I realized how important software redundancy and always updated systems are.

canonical-livepatch status

:question:

From what I understand, the livepatching in Ubuntu doesn’t change the running kernel, just changes the dependency on an old code or module live.

So you’re probably still going to see the same version in uname -a.


Back to my revelation. Basically what happened before was that I was running CentOS servers and doing updates pretty frequently, but no live kernel patching and no actual service restart. So even though I had a new sshd version installed, the one loaded / running was the old version. I never knew that. Then I was tasked with upgrading GitLab and that thing is pretty easy to upgrade, but a bit more involved than just dnf update. After you update via the package manager, you have to run a gitlabctl / gitlab-cli command to apply the update and reload the server. That’s when I started restarting at least some of the services I was updating.

Moving to Void on my own stuff (I wouldn’t switch an infrastructure that I knew I wasn’t going to maintain myself to something that people would have to learn how to use), I discovered the xtools package and an important binary, xcheckrestart that verifies which programs are currently running an older version of what is installed on the system. After every update, I do a xcheckrestart and either close whatever I have open, or reboot my system if required. Worst case, if my window manager gets updated, I just close it, go to a tty and then open it back. If firefox needs a restart, I close and reopen it. On my server, if grafana needs a restart, I restart the runit service. If sshd needs restart, same for it. Unfortunately, my main PC is a rpi, so I don’t get kernel updates frequently.

Following that, when I started using a RPi Alpine Linux router, which by default is a frugal install (diskless), I realized how important is to automate everything to start up to a certain desired state. Ansible is supposed to be just that, but I never got into it. On Alpine, whenever I reboot, if I don’t apply my modifications, everything goes back to how it was before the update. That was actually really neat, because I could hack my way some stuff, if I didn’t need whatever I used, I can just reboot to go back. Or in the rarer case if I break something, a reboot later and I’m up to the races.

What I’m doing there is that I have 2 scripts, one for the firewall and one for the VPN. Alpine boots up, starts the VPN, then applies the rules to allow traffic to go through the VPN and block anything anywhere else. Frugal installs made me realize how important it is to have this set up and how useless livepatching is if you actually restart your services and start them up properly. If you have an automatic procedure for your system to go into the desired state you want it to be in, you don’t need live patching. In fact, servers could basically reboot during the day and if they come back fast, nobody would even notice, unless you have an alerting system in place telling you that the host went down (which you should).

So it’s best to set your infrastructure so that you can have controlled reboots. If you have for example a website that you want to be always available, you don’t need livepatching. Just do at least 2 servers, load-balance them, reboot one, then when it comes up, reboot the other. If your configuration is sane, you don’t even need to intervene. Rebooting often can save you time.

I haven’t taken the step into NixOS yet, but it is very tempting, especially a frugal install, because of how much customization you can have. Here’s a blog post on how awesome NixOS can be and how irrelevant livepatching is in face of a seriously well planned system and redundant software. Bonus points is that with a redundant system, it helps you in many other scenarios than just expected or unexpected reboots or shutdowns, like service crash, system corruption, service misconfiguration etc.
https://grahamc.com/blog/erase-your-darlings

Although it may sound like it, I’m not really trying to convince people to not use livepatching. I’m just presenting the alternative and giving my opinion on livepatching. Obviously I am very biased against it, but don’t make my opinion on it influence you too much. Try both for yourself. :slight_smile:

Good luck!

1 Like

Thank you so much for the explanation! I figured it looked like the orginal kernel was still running when using uname -a

It was one of those things that I read about it and was like Hmm… it’s free for personal use. Eh, I don’t need the redundancy, but I’ll try it out. I ended up not really liking it or actually really needing it so removed it within a week or two.

Like you mentioned load balancing would be much better. Generally my personal site gets so little traffic that I don’t think a two minute reboot matters. Least not now anyway.

Thanks again!

1 Like