Search
21 results for “linux”
Search results
Linux Fundamentals
The command-line building blocks (navigation, permissions, processes, networking, services) every other Linux topic on this site assumes.
Linux Process Management & systemd
Why SIGKILL cannot be caught the way SIGTERM can, and how systemd's Type= decides when a service actually counts as started.
Linux Security and Hardening: SSH, Firewalls, Permissions
How Linux Protects Itself and How Administrators Make It Safer.
Linux Processes and Networking: Signals, Ports, Monitoring
How Linux Runs, Communicates, and Stays Alive.
Linux Storage & Filesystems: Disks, Partitions, Mounts, and Disk Usage
How Linux Stores Data, Mounts Disks, and Survives Failures.
Linux Beginner Labs: Foundations (Understand Linux, Not Just Commands)
Hands-on Linux labs for beginners that build a mental model of how Linux actually works, runnable on any VM, cloud instance, or WSL.
Linux Core Operations: Users, Permissions, sudo, Services
Learn core Linux operations through structured hands-on labs: users, permissions, sudo, package management, and services.
Linux Foundations: How Linux Really Works, Not Just Commands
Learn how Linux actually works (the shell, processes, users, permissions) so commands make sense instead of being memorized one at a time.
Linux Hands-On Labs: Users, Permissions, sudo, and Services
Linux Core Operations: Full Practical Labs (Beginner → Intermediate)
Nano, Vim, and NeoVim on Linux: Beginner to Pro Workflows
Nano vs Vim vs Neovim: Which Linux Text Editor Should Engineers Actually Use?
What is the difference between killing a process with SIGTERM and SIGKILL?
`kill <pid>` sends SIGTERM by default, a request asking the process to shut down, which well-behaved programs catch to close files, finish in-flight work, and exit cleanly. `kill -9 <pid>` sends SIGKILL, which the kernel delivers directly and a process cannot catch, ignore, or clean up after; it is terminated immediately, mid-instruction if necessary. SIGKILL is a last resort for a genuinely hung process; reaching for it by default risks corrupted files or orphaned resources that a graceful SIGTERM shutdown would have avoided.
Why does `ping` succeeding not guarantee an application on that host is reachable?
ping tests only ICMP echo reachability at the network layer; it confirms a host responds to the network, nothing about any specific service running on it. An application listening on a TCP port can be down, crashed, or blocked by a firewall rule that specifically targets that port while still allowing ICMP through, or conversely ICMP itself can be blocked while the actual service is reachable. Confirming an application is actually up requires testing the application layer directly, e.g. `curl` against its port or `ss -tulpn` to confirm something is listening at all.
What does `systemctl enable` actually do, and how is it different from `systemctl start`?
`systemctl start <service>` runs the service right now, in the current boot session only; it will not come back after a reboot. `systemctl enable <service>` creates the symlinks systemd uses to decide what to launch automatically during the boot sequence, so the service starts on every future boot, but does not start it immediately. The two are independent and commonly used together (`systemctl enable --now <service>`) precisely because neither one implies the other.
Why does sending SIGKILL to a stuck process work when SIGTERM doesn't, and what does that cost you?
SIGTERM asks a process to terminate but can be caught by a signal handler, letting the process run its own cleanup logic (closing files, flushing buffers, releasing locks) before actually exiting, or in a broken process, being caught and never acted on at all. SIGKILL cannot be caught, blocked, or ignored under any circumstances, the kernel terminates the process directly, which is why it works on a process SIGTERM couldn't reach. The cost is that none of that cleanup logic runs, a database connection isn't closed cleanly, a temp file isn't removed, a lock isn't released, so SIGKILL is a last resort after SIGTERM has been given a real chance to work, not a default first move.
In a systemd unit, what is the practical difference between Type=simple and Type=forking, and why does that distinction matter for dependency ordering?
With Type=simple, systemd considers the unit started the moment the main process is forked off, it does not wait for the application to finish its own initialization, so anything depending on that unit might start before the service is actually ready to handle requests. Type=forking expects the traditional daemon pattern, the initial process forks and exits once it judges its own startup complete, so systemd marks the unit started as soon as that original process exits successfully, while the actual daemon keeps running as a separate, now-orphaned process. That only tracks the daemonization handoff, not genuine application readiness, a process can exit believing setup is done while it is still finishing initialization in the background, so Type=forking is a better signal than Type=simple but still not a readiness guarantee. Type=notify is the one that actually is readiness-safe: the service explicitly calls sd_notify to tell systemd exactly when it's ready, rather than systemd inferring readiness from process exit behavior at all.
What is the practical difference between ps -ef and ps aux, and why do they show different columns for the same processes?
`-ef` is UNIX-style syntax and `aux` is BSD-style syntax for the same underlying command, and they weren't designed as one consistent interface; mixing them can even be ambiguous depending on other options used. The manual is explicit that BSD-style options change the default output to include process state (STAT) and full command arguments (COMMAND) instead of just the executable name, and BSD-style selection also defaults to showing every process the invoking user owns across all terminals, while UNIX-style selection defaults to processes on the current terminal only. Neither is "more correct," they're two different historical option conventions layered onto the same command, which is why picking one and being consistent about it matters more than which one.
df Says Your Disk Is Full. du Says It Isn't. Both Are Right.
Learn why deleted-but-open Linux files stay on disk, how to find them with lsof +L1, reclaim the space safely, and prevent repeat incidents.
Why Every Container in Your Rolling Deploy Takes an Extra 10 Seconds to Stop
Why npm as PID 1 can prevent Node.js from receiving SIGTERM, trigger Docker's ten-second timeout, and end container shutdown with SIGKILL.
What is the difference between the Baseline and Restricted Pod Security Standards levels, and why are they cumulative?
Baseline blocks the most well-known container privilege-escalation paths, privileged containers, host namespaces, hostPath volumes, dangerous Linux capabilities, while still allowing a fairly permissive pod spec otherwise. Restricted inherits every Baseline rule and adds real hardening on top: it requires running as non-root, forbids privilege escalation outright, requires a restricted seccomp profile, and requires dropping all Linux capabilities except NET_BIND_SERVICE. A read-only root filesystem is not part of either standard, it's a separate hardening measure some organizations layer on as their own policy, on top of, not as part of, Restricted. They're cumulative by design, Restricted is Baseline plus more, so a workload that passes Restricted automatically satisfies Baseline too, and a cluster can apply different levels per namespace based on how much a given workload can be trusted.
Terraform on Azure: Resource Groups, VNets, NSGs, and VMs
Build a secure Azure resource group, VNet, subnet, NSG, public IP, NIC, and Linux VM with production-minded Terraform and validation steps.
Terraform Troubleshooting Guide: Fix the Errors Engineers Actually Hit
Diagnose Terraform initialization, validation, provider, authentication, state, drift, import, replacement, timeout, and CI failures with a safe workflow.