Server Uptime
For how long can a RHEL server stay up/on before a customer should plan for a reboot?
I'd just like to know industry standard best practice.
Responses
Expert
1223 points
Hello Jeffrey,
There is no need at all to reboot your server just because it was up and running for some time. If a reboot is needed or not depends on installed updates. For example if you have installed an kernel or linux-firmware update you need to reboot your server to got the new code up and running.
On RHEL 7 you could check with /usr/bin/needs-restarting -r whether you need to reboot or not. Example output:
$ /usr/bin/needs-restarting -r
No core libraries or services have been updated.
Reboot is probably not necessary.
I had a similar question some time ago. You could find further information in the answer of Ryan Sawhill in this thread.
Best regards, Joerg
Guru
2484 points
Install yum-utils package to use needs-restarting. It is a very useful tool.
How it appears when reboot is required.
[root@hostname ~]# needs-restarting -r
Core libraries or services have been updated:
systemd -> 219-42.el7_4.7
kernel -> 3.10.0-693.17.1.el7
linux-firmware -> 20170606-58.gitc990aae.el7_4
Reboot is required to ensure that your system benefits from these updates.
More information:
https://access.redhat.com/solutions/27943
Guru
9710 points
Hi Jeffrey,
In addition to what Jörg already explained - a typical reason to restart a server would be to activate (make use of) a new kernel.
Generally you don't have to reboot the system, unless there are maintenance tasks necessary like cleaning the fan for example.
You can run the server until the hardware dies - for many reasons it is recommended to use the latest stable kernel though ... :)
Regards,
Christian
Kernel update isn't really a reason to reboot now that live kernel patching is available. glibc/systemd can be an issue, but there are options out there for live patching of some userspace packages (including glibc). Not sure what Red Hat are currently offering in this space.
Spectre/Meltdown was definitely a problem.
Expert
1223 points
Is kernel live patching available with a standard subscription? Or do you need some add-on or different subscription to use it?
Jorg,
I believe it's premium only.. and the kpatch support doesn't appear to be equivalent to standard patching at this point in time.
There is a KB article here, regarding support:
https://access.redhat.com/solutions/2206511
Expert
1223 points
In addition, my colleague just reminded me of an more or less theoretical issue called memory fragmentation. If you never reboot you system at some point in (a long long) time it could happen that your memory is 60% free but due to memory fragmentation your next program won't start with an out of memory exception.
I'm lucky this did never occour to me due to the neccessary reboots after updates.
Expert
1223 points
Jeffrey asked:
I'd just like to know industry standard best practice.
I do not know wheter our best practice is an idustry standard but I would like to tell you how we do it here. I very like the idea that a reboot of a single server should not be an issue for some service or application you are running you business on. So we should not be afraid of server reboots. Some host could crash due to hardware or software issues anytime anyway.
In our environment we run a patch management with ansible. If packages are found which need to be updated the hosts reboot afterwards.
Today we are running around 80 servers with different kind of services and applications here and this setup works for us well.
Regards\ Joerg
Guru
9710 points
I agree with you, Jörg - generally rebooting a server should not be a big problem, one can always choose "the best suitable time" when to do it. I think it is the same as with the topic "What is better, a clean install or an upgrade ?".
There are pros and cons for both methods and in the end there is no total truth ... it is very much opinion based. :)
Regards,
Christian
Completely agree.
Server uptime definitely isn't the badge of honour it was when I first started in the industry, and as time goes on, it is becoming even less relevant.
With deployments using 'cattle' deployment approaches it's hardly relevant at all. For containerised/serverless workloads, and especially those managed by an orchestrator such as OpenShift (kubernetes) uptime is essentially irrelevant if you have a sufficient number of backend container hosts to spread the workload over.
Sadly though, you always find there is the odd server (pet) running an application in the corner that is less tolerant of reboots, either because of implementation architecture or (poor) product support/capability.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.