Think years of experience make you immune to Linux misconceptions? Here are the bad habits, outdated knowledge, and deep technical myths that trap seasoned sysadmins and DevOps engineers.
Back in 2021, I worked alongside a systems engineer with over fifteen years of Unix and Linux experience. He could write complex AWK one-liners from memory and managed dozens of bare-metal database servers.
One Friday afternoon, our monitoring alerts triggered. A primary database node showed only 300 MB of free memory in the dashboard.
Without checking what that memory was doing, he logged into the server and ran a command to drop cached memory directly in production:
echo 3 > /proc/sys/vm/drop_caches
Within milliseconds, disk read activity hit 100 percent. Active database queries that normally took 2 milliseconds began timing out after 30 seconds. The entire web application stalled for five minutes while the kernel frantically re-read essential files from disk back into RAM.
That event taught me something important. Experience alone does not prevent bad assumptions. Linux has changed heavily over the past two decades. Memory management, process scheduling, cgroup limits, and container isolation work very differently today than they did years ago.
Over my 3+ years of working directly with Linux administration, cloud infrastructure, and building open-source server tools, I have seen these same misconceptions pop up across many teams.
Here are eight dangerous Linux myths that experienced engineers still believe, along with the actual kernel mechanics behind them.
1. Low Free RAM Means Your Server Is Running Out of Memory
This is one of the most common myths in systems administration. An engineer opens top or runs free -h, sees 400 MB in the free column on a machine with 64 GB of RAM, and assumes the server is about to crash.
total used free shared buff/cache available
Mem: 62Gi 48Gi 412Mi 1.2Gi 13Gi 12Gi
Swap: 8.0Gi 120Mi 7.9Gi
Why This Myth Exists
In simple desktop operating systems from thirty years ago, unused RAM was viewed as a safe buffer. Many people still think empty RAM is good RAM.
The Kernel Reality
Unused RAM is wasted RAM. The Linux kernel uses idle memory for the Page Cache and file buffers. When your application reads a file from disk, the kernel keeps a copy of those disk blocks in RAM. If the application asks for that same data again, Linux serves it directly from memory at sub-millisecond speed instead of reading slow disk storage.
The key column to watch in modern Linux systems is available, not free:
- Free RAM: Memory that contains absolutely nothing.
- Available RAM: An estimate of how much memory can be given to new applications without causing system slowdowns. This includes free RAM plus cached memory that can be reclaimed instantly.
How It Breaks Production
When engineers panic and manually run echo 3 > /proc/sys/vm/drop_caches, they wipe out the filesystem cache. The kernel is forced to fetch every binary, library, and data file back from disk storage. This triggers massive disk I/O spikes, increases CPU wait times, and causes database queries to time out.
The Better Approach
Never judge system memory health by the free metric. Monitor the available metric and check for active swapping activity using tools like vmstat 1 or sar -B.
2. Setting Swappiness to 0 Disables Swap Completely
Many deployment scripts and performance tuning guides recommend setting vm.swappiness = 0 in /etc/sysctl.conf to prevent servers from using swap space.
sudo sysctl vm.swappiness=0
Why This Myth Exists
On older Linux kernels (before version 3.5), setting swappiness to 0 told the system to avoid swapping until absolutely necessary. Engineers assumed 0 meant "never swap under any circumstance."
The Kernel Reality
Since Linux kernel 3.5, setting vm.swappiness = 0 does not disable swap. Instead, it instructs the memory manager to avoid swapping anonymous memory (like process heap and stack) unless the system is on the verge of an Out-Of-Memory (OOM) event.
However, the kernel will still evict file-backed pages (page cache) to keep memory free.
If your system runs out of memory and has no swap configured, Linux cannot swap out inactive memory blocks. It has only one choice left: invoke the OOM Killer (mm/oom_kill.c) to terminate heavy processes like PostgreSQL, MySQL, or Java applications.
How It Breaks Production
Disabling swap entirely or relying on swappiness = 0 removes an early warning buffer. Without swap, your system moves straight from normal memory usage to instant OOM process terminations without giving monitoring tools time to alert you.
The Better Approach
Set vm.swappiness to a low value like 10 or 1 rather than completely turning off swap. Keep a small swap file (1 GB to 2 GB) even on large cloud instances so the kernel can move stale, unread memory pages out of RAM safely.
3. High Load Average Always Means High CPU Usage
You get a high-priority alert: Server Load Average is 42.0 on an 8-core CPU! You quickly log in, open top, and find that CPU utilization is sitting at only 5 percent.
top - 14:22:10 up 45 days, 3:12, 2 users, load average: 42.10, 38.45, 30.12
%Cpu(s): 2.3 us, 1.1 sy, 0.0 ni, 12.4 id, 84.2 wa, 0.0 hi, 0.0 si, 0.0 st
Why This Myth Exists
On traditional Unix systems (like BSD), load average counted only processes currently running on a CPU or waiting for CPU time. Many engineers assume Linux handles load average the exact same way.
The Kernel Reality
In 1993, Linux kernel creator Linus Torvalds modified load average calculations. In Linux, load average counts both:
- Processes in Task Runnable (
R) state: Using CPU or waiting in the CPU queue. - Processes in Uninterruptible Sleep (
D) state: Waiting for disk I/O, network storage locks, NFS responses, or kernel locks.
If your storage array slows down or a network mount hangs, dozens of threads block while waiting for disk operations. They enter the D state. The CPU itself is completely idle, but the load average rises sharply.
Notice the 84.2 wa in the top output above. That wa stands for I/O Wait. The CPU is not busy processing calculations; it is doing nothing while waiting for slow disk operations to complete.
How It Breaks Production
Engineers who mistake high load for high CPU usage often upgrade to bigger CPU instances or restart application services. Neither fix works because the root bottleneck is slow disk storage, a failing drive, or network latency.
The Better Approach
Check process states using ps aux | grep ' D ' or inspect disk latency using iostat -xz 1 to find out whether high load comes from CPU demand or storage delays.
4. kill -9 Is the Normal Way to Stop Frozen Processes
When a process does not close immediately, many developers and admins jump straight to forcefully killing it:
kill -9 <PID>
Why This Myth Exists
kill -9 sends the SIGKILL signal, which instantly stops the target process. It feels effective because the process disappears from the system right away.
The Kernel Reality
Linux process signals are designed for graceful shutdown:
-
SIGTERM(Signal 15): Asks the process to shut down cleanly. The application catches this signal, closes open file handles, flushes database write buffers, finishes current requests, and removes temporary lock files. -
SIGKILL(Signal 9): Handled directly by the kernel, skipping the process entirely. The application is given zero milliseconds to clean up state.
When building AiroShare, my open-source local file server engine, clean process handling was crucial. If an application server is forcefully killed with SIGKILL while listening on HTTP or FTP ports (like port 9900 or 2121), socket bindings can remain stuck in TIME_WAIT state, preventing clean application restarts until port locks time out.
How It Breaks Production
Using SIGKILL on databases or file servers causes data corruption, half-written log entries, and orphan lock files. When the process starts up again, it may crash or take a long time attempting crash recovery.
The Better Approach
Always send SIGTERM (kill <PID>) first. Give the process several seconds to complete clean teardown. Only use SIGKILL as a last resort when a process is unresponsive to standard termination signals.
5. Root Inside a Docker Container Cannot Harm the Host Machine
A common assumption in cloud deployments is that containerization works like hardware virtualization. People assume running as root inside a container is safe because it is isolated inside its own environment.
Why This Myth Exists
Containers feel like lightweight virtual machines. Because containers have separate filesystems and process lists, developers assume the container boundary acts as a hard security wall.
The Kernel Reality
Containers are not virtual machines. A container is simply a standard Linux process running directly on the host kernel, restricted by Linux kernel features:
- Namespaces: Restrict what a process can see (process tree, network interfaces, mount points).
- Control Groups (cgroups): Restrict how much resource a process can use (CPU, RAM, disk I/O).
By default, UID 0 inside a container maps directly to UID 0 (root) on the host kernel unless User Namespaces (userns-remap) are explicitly enabled.
If an attacker finds an exploit in your web application and breaks out of container namespace boundaries (via kernel exploits, mounted Docker sockets, or exposed /proc paths), they gain full root privileges on the underlying host server.
How It Breaks Production
Running containerized microservices as root creates severe security risks. A single vulnerability in a web dependency can compromise your entire host operating system.
The Better Approach
- Always set a non-root user in your
Dockerfile:
USER 10001:10001
- Drop unneeded kernel capabilities:
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
- Enable user namespace remapping in your container runtime configuration.
6. chmod 777 Is a Quick and Safe Fix for Permission Errors
When a developer runs into permission errors while setting up web servers, file uploads, or scripts, they often run:
chmod -R 777 /var/www/html
Why This Myth Exists
Permission errors can be frustrating. chmod 777 grants read, write, and execute access to everyone on the system (User, Group, Others), instantly clearing permission error messages.
The Kernel Reality
Setting 777 allows any local user or service account to read, modify, overwrite, or execute your files.
Furthermore, several critical Linux services actively reject files with loose permissions:
-
OpenSSH: Will refuse to authenticate if
~/.ssh/authorized_keyshas permissions wider than600. - Systemd: Ignores unit files if file permissions are set too loosely.
- Cron: Skips scheduled cron jobs if permission settings are unsafe.
How It Breaks Production
If an attacker exploits a minor file upload vulnerability in a web application hosted inside a 777 directory, they can upload malicious scripts and execute them immediately with full write access to the application tree.
The Better Approach
Fix ownership using chown rather than loosening permissions with chmod 777:
- Set ownership to the correct service user:
sudo chown -R www-data:www-data /var/www/html
- Apply secure file and folder permissions:
find /var/www/html -type d -exec chmod 755 {} +
find /var/www/html -type f -exec chmod 644 {} +
7. A System Reboot Is Required After Upgrading Linux Packages
Coming from a desktop Windows background, many administrators believe that after running system updates, you must reboot the server to apply changes.
Why This Myth Exists
Legacy operating systems often lock system files during runtime, requiring a complete reboot after security updates.
The Kernel Reality
Linux allows you to update libraries, software packages, and system utilities while the system is running. When you update a package using apt or dnf, the old files on disk are unlinked and replaced with new binaries immediately.
However, processes that were already running in memory continue executing the old version from RAM until those services are restarted.
Rebooting the entire server is required only when updating the Linux kernel itself (unless you use live patching utilities like kpatch or Canonical Livepatch).
For standard library updates (like OpenSSL or system packages), you only need to restart the affected service:
sudo systemctl restart nginx
How It Breaks Production
Rebooting servers unnecessarily causes avoidable service downtime, disrupts active network connections, and lowers system availability metrics.
The Better Approach
Use automated tools like needrestart (on Debian/Ubuntu) or dnf needs-restarting (on RHEL/Fedora) to identify which running services need a restart after updates without rebooting the server:
sudo needrestart -v
8. Setting Low nice Values Guarantees CPU Allocation
When an important background process needs to run faster, engineers often adjust its nice priority value:
nice -n -20 /usr/bin/heavy-data-processing
Why This Myth Exists
The nice command scale ranges from -20 (highest priority) to 19 (lowest priority). People assume setting -20 forces the CPU to give all its processing power to that specific process.
The Kernel Reality
The Linux Completely Fair Scheduler (CFS) calculates CPU time shares using relative weights based on nice values.
However, two major factors limit the impact of nice:
- CPU Contention Required: If the CPU is not fully saturated, nice values have zero noticeable impact because the CPU has enough headroom to handle all tasks.
-
Control Groups Override
niceSettings: On modern Linux systems managed by systemd and cgroups v2, CPU limits configured inside cgroup unit files (CPUWeight=,CPUShares=) override process-levelnicesettings.
If a process is placed inside a restricted cgroup slice, setting nice -20 inside that process will not allow it to bypass its cgroup CPU limits.
How It Breaks Production
Relying on nice values to prioritize background batch processing fails in containerized environments (Docker, Kubernetes) because container CPU limits are enforced at the cgroup level.
The Better Approach
Manage process CPU allocation using cgroups or systemd slice configurations:
[Service]
Slice=custom-workload.slice
CPUWeight=200
💡 Surprising Linux Fact
Did you know that the /proc filesystem on Linux consumes 0 bytes of disk space?
/proc is not a physical directory on your hard drive. It is a virtual filesystem created dynamically in memory by the Linux kernel. When you view files like /proc/meminfo or /proc/cpuinfo, the kernel generates that text content on the fly directly from internal kernel data structures!
Conclusion
Linux is an remarkably reliable operating system, but many common practices passed down through blog posts and old tutorials are outdated. Understanding how the kernel manages memory, calculates load average, isolates container processes, and handles system signals will help you build faster, more secure production environments.
Which of these Linux myths have you encountered on your engineering team? Have you seen system issues caused by dropping caches or setting swappiness = 0 in production? Share your thoughts and experiences in the comments below!
About the Author
Asep Sayyad is a Linux and DevOps engineer passionate about Linux administration, automation, cloud technologies, containers, and open-source software. He enjoys solving real-world infrastructure challenges and sharing practical knowledge through in-depth technical articles, tutorials, and hands-on guides.
His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.
Connect with Me
Portfolio: https://asepsayyad007.in
GitHub: https://github.com/asepsayyad007
LinkedIn: https://www.linkedin.com/in/asepsayyad
Enjoyed this article?
If you found this guide helpful, consider:
- Starring my open-source projects on GitHub.
- Sharing this article with fellow Linux and DevOps engineers.
You can also follow me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source. Thanks for reading, and enjoy your learning!
© 2026 Asep Sayyad
Top comments (0)