fmaury/seirdy.one
1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-10 00:12:09 +00:00
Code Issues Projects Releases Wiki Activity

New note: Kexec considered overkill

Browse source
This commit is contained in:
Rohan Kumar 2022-10-23 22:09:27 -07:00
parent f7d9a9ae75
commit 1f3e5ebd3c
No known key found for this signature in database
GPG key ID: 1E892DB2A5F84479
1 changed files with 15 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
content/notes/kexec-considered-overkill.md Normal file
View file

@ -0,0 +1,15 @@
---
title: "Kexec considered overkill"
date: 2022-10-23T22:09:27-07:00
replyURI: "https://community.mojeek.com/t/kexec-boot-a-new-kernel-without-power-cycling/"
replyTitle: "Kexec: Boot a new Kernel without Power Cycling"
replyType: "DiscussionForumPosting"
replyAuthor: "Mike"
replyAuthorURI: "https://community.mojeek.com/u/mike/"
---
Avoid kexec if you don't need it: it opens new vulnerabilities, and is better left disabled for most use-cases. Redundancy and failover should eliminate the need when hosting a typical service. Even without the risks, there are other reasons to reboot: updates to shared libraries, SELinux policies, and init systems often warrant one.
One use-case that benefits from kexec is pubnix systems with many logged-in users. If you need to apply an unscheduled security patch while causing minimal disruption, then live-patching makes sense.
With some boot optimization, I can hit 99.9% uptime even if I reboot 2-3 times per week on Fedora. With failover, these reboots should have negligible impact.