Reboot Last - The Windows Habit That Hurts Linux and FreeBSD Operators

The Reflex That Came From Somewhere Else

A specific habit has propagated from the consumer operating system
world into the professional Linux and FreeBSD world. The habit is
to reboot the system as the first response to any unexplained
problem. The application is misbehaving — reboot. The service is
slow — reboot. The disk is full — reboot. The network is acting
strange — reboot. The reflex is so ingrained in the engineers who
grew up on Windows that they reach for it before they reach for
any diagnostic tool.

On Windows, the reflex is sometimes correct. The Windows kernel
and user-mode runtimes have historically had memory leaks in
long-running processes. Windows Update has trained the user to
expect a reboot at the end of every significant change. Many
Windows services lack clean reload mechanisms. Configuration
changes often require restarting the entire system to take
effect. The "have you tried turning it off and on again" line is
a joke because it is also frequently the answer. Microsoft's own
support documentation, for several decades, has recommended the
reboot as an early troubleshooting step. The reflex was trained
deliberately.

On Linux and FreeBSD, the reflex is almost always wrong. This post
is the case for treating reboot as the last debugging step, not
the first.

What You Lose When You Reboot

A reboot destroys the running state of the system. The running
state is, in any debugging scenario, the only authoritative
description of what is actually wrong. The process table at the
moment of failure tells you which processes are consuming
resources. The open-file table tells you what each process has
its hands on. The network socket table tells you what
connections are in flight. The kernel ring buffer contains
messages from the last several minutes that describe what the
kernel itself was doing. The /proc and /sys hierarchies expose
the live state of every subsystem.

All of this is wiped at reboot. The system that comes back is a
fresh boot, with no evidence of what was broken, except whatever
was persistent on disk and made it into a log file. The
persistent state often does not contain enough information to
understand the failure, because the most useful diagnostic
information was in the live state.

The other thing you lose is the verification that you actually
understood the problem. A system that "works after a reboot"
tells you nothing about whether the underlying cause has been
fixed. It tells you only that whatever was wrong is no longer
manifesting at this moment. The cause is still there, waiting.
It will manifest again, and you will have learned nothing from
the first occurrence that will help you understand the second.

The Right Debugging Order on Unix

The Unix debugging tradition, accumulated across forty years of
operators who could not casually reboot production systems, has a
clear hierarchy. Reboot is at the bottom of it.

The first step is to read the logs. journalctl -xeu <service>
on systemd-Linux, tail /var/log/messages and the
service-specific files in /var/log/ on FreeBSD, and dmesg
for kernel-level events. The logs almost always contain the
information needed to understand what happened. The discipline is
to read them carefully rather than scrolling past them.

The second step is to check process state. ps auxf shows the
process tree. top or htop shows resource consumers. ss -tlnp
shows listening sockets and the processes that own them. lsof -p <pid> shows what a specific process has open. The state of
the broken process or service is usually visible here.

The third step is to check resource exhaustion. df -h shows
filesystems. free -m shows memory. vmstat 1 5 shows the
kernel's view of system pressure. iostat -xz 1 5 shows disk
performance. The vast majority of "the system is acting strange"
problems trace to one of these four categories of resource
running out.

The fourth step, if the problem is configuration-related, is to
reload the relevant service without restarting it.
systemctl reload <service> on Linux. service <service> reload
on FreeBSD. Or for daemons that respond to SIGHUP, kill -HUP <pid>. The vast majority of well-written daemons reload their
configuration in place without losing any state.

The fifth step is to restart the specific service, not the
system. systemctl restart <service> or service <service> restart. This loses only that service's state, which is the
minimum cost.

The sixth step, after all of the above have produced an
understanding of what was wrong and a hypothesis about how to fix
it, is to consider whether a reboot is necessary. Usually it is
not. Sometimes, after a kernel update, after a libc update, after
specific kernel subsystem changes, or after the kind of
mysterious hardware-adjacent issue that nobody fully understands,
a reboot is the right answer. By that point, however, the
operator has at least extracted whatever diagnostic information
the live state contained, and the reboot is a deliberate
intervention rather than a reflex.

When Reboot Is Actually Correct

To avoid overselling the position: there are cases where reboot
on Linux or FreeBSD is correct. These cases are narrower than the
reflex suggests but real.

Kernel security updates require a reboot to take effect, and
running an unpatched kernel longer than necessary is its own
operational risk. This is reboot for security, not reboot for
debugging.

Certain kernel subsystems — graphics driver state corruption,
specific NIC firmware paths, occasional storage controller
issues — can enter states that require module unload-reload or
full reboot to recover. These cases are rare but real.

Hardware-level issues, particularly anything involving system
firmware (BIOS/UEFI), often need a full power cycle. A reboot is
the first step toward diagnosing whether the issue is
software-recoverable.

After significant infrastructure changes — changing the boot
loader, adjusting kernel command-line parameters, migrating root
filesystems — a reboot is the verification step that the new
configuration actually works.

In each of these cases, the reboot is a deliberate action taken
for a specific reason. It is not the first response to "something
is wrong."

Closing

The Unix design philosophy assumes that the system runs for a
long time. The kernel does not leak. The daemons are long-lived.
The configuration is reloadable. The diagnostic tools expose the
live state. The whole stack is designed for the operator who
investigates rather than the operator who resets.

The operators who do best with these systems are the ones who
have unlearned the reboot reflex. The investigation produces a
real understanding of what was wrong. The fix addresses the cause
rather than masking the symptom. The system continues to run for
years because the operator's habits match the system's design
assumptions.

The next time something on a Linux or FreeBSD system is acting
strange, the right first move is to read the logs. The right
second move is to check process state. The right third move is
to check resource exhaustion. Reboot belongs further down the
list than the consumer-OS reflex puts it, and the further down it
goes, the better the operator becomes at understanding the
systems they run.