
Master Your Linux System: Key Tools for Performance, Security, and Control
The Linux command line is a gateway to unparalleled system control. While many users are familiar with the basics, a deeper knowledge of specific utilities can transform your workflow, enhance security, and boost performance. Whether you’re managing a server, developing in containers, or simply running a Linux desktop, mastering the right tools is essential.
Here, we explore a curated set of powerful commands and concepts that can help you level up your skills, from optimizing memory usage to protecting critical, long-running tasks.
Boost System Performance: Understanding zswap vs. zram
When your system runs out of physical RAM, it turns to a swap space on your hard drive or SSD. This process, known as swapping, is significantly slower than accessing RAM and can lead to a sluggish system. Linux offers two powerful mechanisms to mitigate this by using RAM compression: zswap and zram.
zram creates a compressed block device directly within your system’s RAM. This virtual device acts as a swap disk. When the system needs to swap, it sends pages to the zram device, where they are compressed and stored. This is much faster than writing to a physical disk.
- Best for: Systems with no dedicated swap partition or a very slow swap device (like an SD card on a Raspberry Pi). It effectively increases the amount of usable memory at the cost of some CPU cycles for compression.
zswap, on the other hand, is not a swap device itself but a compressed cache that sits in front of your existing swap device. When a memory page is about to be swapped out, zswap intercepts it, compresses it, and stores it in a dynamically allocated RAM pool. Only when this pool is full are the least-used pages evicted to the actual swap disk.
- Best for: Systems that already have a swap partition. It acts as a performance buffer, dramatically reducing the amount of slow disk I/O and improving responsiveness under memory pressure.
The key difference is simple: zram creates a swap device in RAM, while zswap acts as a fast, compressed cache for an existing swap device. Choosing the right one depends entirely on your system’s hardware configuration and needs.
Map Your Digital Footprint with Subfinder
In cybersecurity, understanding your attack surface is the first step toward securing it. An organization’s digital footprint often includes numerous subdomains for different services—blog.example.com, api.example.com, dev.example.com, and so on. Attackers actively seek these out to find forgotten, unpatched, or misconfigured entry points.
Subfinder is a powerful reconnaissance tool designed to discover valid subdomains for a given domain. It rapidly queries various public data sources, such as search engines and internet archives, to compile a comprehensive list.
For system administrators and security professionals, this is an invaluable defensive tool. By running it against your own domains, you can:
- Identify all publicly accessible assets.
- Discover legacy or “shadow IT” services you weren’t aware of.
- Ensure every subdomain is properly monitored, patched, and secured.
Using Subfinder automates the discovery of subdomains, providing a complete view of an organization’s publicly accessible assets. A basic scan is as simple as running:
subfinder -d yourdomain.com
Regularly auditing your subdomains is a critical security practice that helps close potential gaps before they can be exploited.
Effortless Kubernetes Debugging with kubectl logs
Applications running inside Kubernetes (K8s) containers can sometimes feel like a black box. When a pod is crashing or misbehaving, your first line of defense is to check its logs. The kubectl logs command is the essential tool for this job.
At its simplest, you can view the logs of a running pod with:
kubectl logs <pod-name>
This command dumps the entire log output from the primary container within the specified pod. However, its real power lies in its optional flags:
Stream logs in real-time: To see new logs as they are generated, use the
-for--followflag. This is perfect for monitoring live application behavior.
kubectl logs -f <pod-name>Access logs from a specific container: If a pod contains multiple containers (a common pattern for “sidecar” containers), you must specify which one you want to inspect with the
-cflag.
kubectl logs <pod-name> -c <container-name>View previous logs: If a pod is stuck in a crash loop, you can view the logs from its previous, terminated instance using the
-por--previousflag. This is crucial for diagnosing startup failures.
kubectl logs <pod-name> --previous
Mastering kubectl logs is fundamental for troubleshooting and gaining visibility into your containerized applications, turning a complex distributed system into something far more manageable.
Protect Critical Tasks with systemd-inhibit
Have you ever started a critical system backup or a massive file transfer, only to have your laptop automatically go to sleep and interrupt the process? Or perhaps a system-wide automatic update rebooted the machine in the middle of a long-running compilation. The systemd-inhibit command provides an elegant solution to this problem.
This utility allows you to run a command while placing a temporary “inhibition lock” on specific system actions. These actions can include shutdown, sleep, reboot, or even handling the laptop lid switch.
The syntax is straightforward:
systemd-inhibit --what=[action] --why="[reason]" [your_command]
--what: A colon-separated list of actions to block (e.g.,shutdown:sleep:idle).--why: A human-readable description of why the lock is in place. This message will appear to any user who tries to initiate a blocked action.[your_command]: The long-running process you want to protect.
For example, to run a critical backup script using rsync and prevent the system from sleeping or shutting down until it’s finished, you would use:
systemd-inhibit --what=sleep:shutdown --why="Critical system backup in progress" rsync -a /home/ /mnt/backup/
systemd-inhibit ensures that long-running commands complete without being interrupted by system events. The lock is automatically released once the command finishes, making it a safe and reliable way to protect your most important tasks.
Source: https://linuxhandbook.com/newsletter/25-27/


