When to reboot a Linux computer

Last Updated on 09/20/2019 by dboth

I belong to several listservs, on-line fora, and groups focused on Linux. Over the years there has been a great deal of discussion about when a Linux computer should be rebooted. One recent discussion has taken place on one of the groups I belong to on LinkedIn.

There are many different opinions but they all boil down to one of two responses.

  • When it needs to be rebooted.
  • On a regular schedule.

Everything else discussed on all of these fora is merely a variation on one of these two themes, or a combination of the two.

In my experience, and in the experience of all the real Linux administrators I know, there has never been a need to reboot any Linux host unless the kernel has been updated and, in some opinions, when glibc is updated. No Linux host should ever be rebooted on a regular schedule; it is just not necessary.

Regular rebooting is a Windows practice because Windows is so unstable and has many flaws such as memory leaks. Who has never experienced the fact that Windows slows to a crawl after a few days or weeks of operation? Everyone who uses it has seen that phenomenon. Many organizations reboot all Windows servers on a regular basis just to clean up the cruft that accumulates and causes them to run slowly and crash.

Here is a list of things you can do on a Linux computer that do NOT require a reboot.

  • Install new software. It is never necessary to reboot a Linux computer after installing new software. Ever.
  • Upgrade existing software, even system software except for the kernel and possibly glibc. I update my systems on a regular basis. General updates never require a reboot. And you can choose the time you want to reboot if the kernel is updated. Note that Linux never forces one or more reboots during the updates themselves.
  • Restart a service that has crashed or is performing poorly. On more than one occasion I have had a DOS attack against one of the web sites I run or administer that caused the web site to be very slow and, in a couple instances, to bog down the entire computer. I simply stopped the web service (httpd) until the attack dwindled to nothing and restarted it. Meanwhile, all the rest of the services running on that host continued to run.
  • Add more space to a logical volume. When the root partition — or any other — fills up, it can be expanded dynamically, adding as much space as required, even while the computer and all its services are running. I once was in the process of installing Linux on a virtual machine using VirtualBox. The filesystem on the host ran out of space halfway through the installation. VirtualBox was smart enough to detect the problem and notify me and place the VM into a pause mode. I use the LVM tools to add space to the logical volume, resized the filesystem on the logical volume, restarted the VM, and completed the installation.
  • Making changes to kernel tuning parameters. The kernel can be tuned by making changes to the contents of some files in the /proc/sys directory of the /proc filesystem. These changes take effect immediately and do not require a reboot.
  • Changing the hostname. This requires only the use of the hostname command. The hostname is changed immediately. Running applications and terminal sessions do not recognize this change because they are still using the environment they started with, including the hostname. The $HOSTNAME environment variable can be changed for terminal sessions and applications that require the hostname can be restarted if necessary. Worst case, a user can logout of their current session and log back in. A reboot is NOT required.
  • Cleaning the /tmp filesystem or directory.

I have direct experience with several Linux servers that have run for well over a year without having to reboot. The only reason these servers were rebooted was due to a kernel update, system hardware maintenance, or due to a power failure for a longer period of time than the UPSes could support them.

Other Linux servers and workstations I use or administer run for many months and are only rebooted when the kernel is updated or other system maintenance such as hardware upgrades needs to be performed.

Here is one of the more amazing stories on the LinkedIn discussion. I thought this response in particular to be very interesting and quite an illustration of the rock-solid stability of Linux. Read it for yourself below, and you can also see the entire discussion at the link.

How often do you people reboot the Linux servers ?

Reprinted with permission of Fred Moore.
Security Consulting (physical/electronic), Security Design and review, Project Management, Sales

Other than a kernel upgrade there are very few reasons to restart a server. I once had Debian workstation running for 5 years and 2 months, never powered down, never rebooted, till we lost power for 5 days after a hurricane.

This is not windows, very few experienced sys admins reboot servers, as you can restart any service at any time (a few exceptions). I once had a customer that lost a server for several years, it was still functioning, they still had access, it was accessed daily, was still running the access control system between cities, They knew it was on premises, because they could kill the port on the switch, and it would stop. However they could not do a physical inventory, kinda made them crazy, They had 50+ servers running, they finally found it. During a remodel of the data center (two years prior), one night the contractor had closed it in behind some drywall. At the time this was their only Linux box, everything else was windows. Upon finding the server, they converted 90% of the windows boxes within a year. This was a management mandate, they now have 40% less sysadmins

Other responses indicated that people have Linux hosts with years of uninterrupted uptime. One such is shown below.

[gfrear@ns1 ~]$ uptime
07:19:33 up 2141 days, 12:19, 1 user, load average: 2.33, 1.93, 1.81

That is 5.88 years of uninterrupted uptime.

So the bottom line is only reboot a Linux computer when the kernel is updated.