Today's article is about when you last rebooted your Linux box.

KGIII

Super Moderator
Staff member
Gold Supporter
Joined
Jul 23, 2020
Messages
11,498
Reaction score
9,993
Credits
95,326
It's a cleaned up version from the old site, written because I wasn't quite up to snuff at the time. Still, it's updated with more information and that's done.


Feedback is awesome. I've gotta get a number of articles ahead, 'cause I know winter is coming and Mother Nature is bound to take me offline for a few days.
 


I reboot at least once everyday just to set everything back to zero so to speak.

I reboot after installing updates and I know this isn't always needed because this is Linux.

I also beleive it's a good idea to power off and power on computers from a cold start once in awhile because I never turn my computers off.
 
I pretty much only reboot when there's a kernel update or some other cause, but mostly just for kernel updates - unless it's a system I test with. If I test with that system, I'll reboot into a live USB fairly often to test the daily Lubuntu build.
 
I only reboot my homeserver once every few months sometimes more for kernel updates, also if systemd gets updated your system usually needs a reboot. On Rhel based systems you can use the command needs-restarting, from the package yum-utils, to see if your system needs a reboot after having installed updates.
 
unless it's a system I test with. If I test with that system, I'll reboot into a live USB fairly often to test the daily Lubuntu build.
That makes sense.

I think rolling distros / releases require restarts more often than LTS distros being the software and kernel are always changing although I may be wrong about that.

In PCLinuxOS every so many weeks a new kernel is released and installed which follows the Linux kernel archives.

 
I've been known to use the live kernel patching solutions and not reboot servers for a long time.

I also don't really use any rolling releases outside of VMs. It's not that I have anything against them, it's that I prefer other distros.
 
I've been known to use the live kernel patching solutions and not reboot servers for a long time.

I also don't really use any rolling releases outside of VMs. It's not that I have anything against them, it's that I prefer other distros.
What do you use for live kernel patching, kpatch?
 
Last edited:
I've used both that and Canonical's Live Patch. I no longer use Canonical's Live Patch. It's only available as a Snap on modern Ubuntu.

There was a third solution but darned if I can recall the name right now. I want to say that RHEL now has it enabled and has for the past couple of versions, but I haven't read into it.
 
I may try it on a test system but it's good to reboot a server at least once every few months so you know it will come backup if it loses both of it's power supplies, my homeserver is basically a desktop system which I placed in a corner somewhere so it has 1 powersupply. It also seems live patching with kpatch is only recommended to be used when it's not possible to have down-time with a system during release of important security updates.
17.1. Limitations of kpatch
  • The kpatch feature is not a general-purpose kernel upgrade mechanism. It is used for applying simple security and bug fix updates when rebooting the system is not immediately possible.
  • Do not use the SystemTap or kprobe tools during or after loading a patch. The patch could fail to take effect until after such probes have been removed.
Sorry for going somewhat off topic, but maybe only a little since after installing kernel updates a system requires a reboot.
 
I also don't really use any rolling releases outside of VMs. It's not that I have anything against them, it's that I prefer other distros.
I hear ya. LTS distros were all I used to use.

I'm using semi rolling / rolling releases more and more nowadays.
The only LTS distro I'm using is Ubuntu 20.04.2 because of WayLand.
 
Something to add to your article but it's more for advanced users since it would probably confuse beginners searching through log files. You can also check in syslog for one of these lines to see when your system was last starting up.
Aug 9 19:26:07 raven kernel: Command line: BOOT_IMAGE=(hd3,gpt2)/vmlinuz-4.18.0-305.10.2.el8_4.x86_64 root=/dev/mapper/vg0-root ro crashkernel=auto resume=/dev/mapper/vg0-swap rd.lvm.lv=vg0/root rd.lvm.lv=vg0/swap rhgb quiet systemd.unified_cgroup_hierarchy=1

Aug 9 19:26:16 raven rsyslogd[4012]: [origin software="rsyslogd" swVersion="8.1911.0-7.el8_4.2" x-pid="4012" x-info="https://www.rsyslog.com"] start
Depending on the distribution the lines may differ a bit in how they look but they should look somewhat similar.
 
I may try it on a test system but it's good to reboot a server at least once every few months so you know it will come backup if it loses both of it's power supplies,

Yeah, these days I don't worry so much about giant uptime and just reboot now and again. I may check out RHEL's solution - as RHEL is free for SOHO use.

I hear ya. LTS distros were all I used to use.

I'm a big LTS kinda guy. I like the consistency. I also don't need latest and greatest.

Something to add to your article but it's more for advanced users since it would probably confuse beginners searching through log files.

I know darned well that you know how to leave a comment on the site. :cool:

For code, it's <code>foo</code> and not brackets. (I just tested to make sure.)
 
I believe the original live kernel path was KSplice and Oracle purchased it and closed sourced it like the jerks they are.

Now Redhat, Canonical, and SUSE have their own live patching. I really haven't used them though. With the exception of my database servers, (specifically some of my MariaDB servers) most of my servers are redundant and I can pull them one by one for patching and reboot.
 
I know darned well that you know how to leave a comment on the site. :cool:

For code, it's <code>foo</code> and not brackets. (I just tested to make sure.)
I used code code tags like the example you gave but it doesn't look like a code block now and my username showed auto-corrected to a wrong username again. Is there a way for me to sign up so that so that it the correct username will be associated with the e-mail address I use?
 
I believe the original live kernel path was KSplice and Oracle purchased it and closed sourced it like the jerks they are.
That is correct the only way to use KSplice if you have one of an Oracle subscriptions if I remember correctly, wouldn't be surprised if it would be the most expensive one available since we are talking about Oracle here.
 
I hear ya. LTS distros were all I used to use.

I'm a big LTS kinda guy. I like the consistency. I also don't need latest and greatest.
I don't need the latest and greatest either.

However.

The new LTS releases don't work well on my old Frankenstein computers.
The semi rolling releases and rolling releases work well on my old Frankenstein computers.

I kinda got an idea why but can't say for certain other than the distros I use are Debian base.

I ain't quite sure what the hell PCLinuxOS is but it sure beats the Debian / Ubuntu distros on my old Frankenstein computers.
 
Sorry for going somewhat off topic, but maybe only a little since after installing kernel updates a system requires a reboot.

I'm never much of a stickler when it's a topic I've started from the site. That's where I get a bunch of great ideas!

I'm using semi rolling / rolling releases more and more nowadays.

That's one of the *many* reasons why I love Linux. I love the choices we get to make. I don't think we have too many distros or anything like that.
 
What do you use for live kernel patching, kpatch?

I have. Right now I don't have anything live patching in 'production'. I do have an old 18.04 Ubuntu Server with it from before it required Snap, it's in ESM mode these days so it's pretty static. That's why I said "I have been known to." My bad for not making that clear. In production, I just reboot 'em now and then. The thread has gotten confusing at this point.

The semi rolling releases and rolling releases work well on my old Frankenstein computers.

I'd have guessed it would be the exact opposite. I'd have guessed wrong!
 
Now Redhat, Canonical, and SUSE have their own live patching.

My plan is (when time allows) to try the new RHEL native version, as it's now free for SOHO use. With RHEL going free for SOHO, it does take some of the sting out of their CentOS choices.
 


Top