Search
30 results for “signals”
Search results
Linux Processes & Networking: Monitoring, Signals, Ports, and Connectivity
How Linux Runs, Communicates, and Stays Alive.
Linux Process Management & systemd
Why SIGKILL can't be caught or ignored the way SIGTERM can, how systemd's Type= actually decides when a service counts as "started," and the difference between the ps command's BSD and UNIX option styles.
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.
Why does Python's documentation say a class defining mutable objects with a custom __eq__ should not implement __hash__ at all?
If an object's hash is derived from fields that can change after the object is already stored as a dict key, mutating it changes its hash value, but the object stays in whatever bucket it was originally placed in based on the old hash, so a subsequent lookup computes the new hash, looks in the new (wrong) bucket, and fails to find an object that is, in fact, still in the dictionary. Making a mutable object unhashable by default (which not defining `__hash__` effectively signals) prevents this specific class of bug entirely, at the cost of not being able to use that object as a dict key or set member at all, a deliberate, documented trade-off favoring correctness over convenience.
What is the difference between monitoring and observability?
Monitoring means watching a predefined set of signals for known failure modes, dashboards and alerts built around questions you already knew to ask ("is CPU above 80%?"). Observability is a property of a system: how well you can answer new, previously-unasked questions about its internal state using only its external outputs (logs, metrics, traces), without shipping new code. Monitoring tells you something is wrong; observability is what lets you figure out why, including for failure modes nobody anticipated when the dashboards were built.
How to Set Up Azure Monitor Alerts, Action Groups, and Processing Rules (Step‑by‑Step Guide)
Modern cloud environments generate constant signals, metrics, logs, and events. Without proactive monitoring, critical changes such as accidental VM deletion can go unnoticed. Azure Monitor provides a centralized platform for collecting, analyzing, and acting on telemetry from Azure resources. This…
Step-by-Step Guide: Creating a Client Computer and Joining It to a Domain (Hyper-V Lab Setup)
As part of building a realistic domain based environment, this lab demonstrates how to create a client computer and join it to an existing Active Directory Domain Services (AD DS) domain hosted on Windows Server 2019 , using Hyper V. A domain environment is incomplete without client machines. Joini…
An O(n^2) sort can be faster than an O(n log n) sort for small inputs. Why, and why doesn't that matter for a general-purpose sort function?
Big O describes asymptotic growth, not actual runtime, and O(n^2) algorithms often have smaller constant factors and simpler inner loops (no recursion or merge-buffer overhead) that make them genuinely faster in wall-clock time for small n, even though the more sophisticated O(n log n) algorithm would eventually win as n grows. This is exactly why production sort implementations, including Timsort, special-case small subarrays with a simple insertion sort internally rather than using the full merge-sort machinery on tiny inputs, getting the best of both regimes instead of picking one algorithm for every input size.
Why is scanning IaC source (Terraform files) not sufficient on its own, without also checking the plan?
Static scanning of Terraform source can catch some misconfigurations (a hardcoded insecure default) but can't see values that only exist after variables, data sources, and module composition are actually resolved, an insecure setting could depend on a variable supplied at runtime that static source scanning alone can't evaluate. The plan is the fully resolved, concrete set of resources Terraform is actually about to create or change, which is why policy-as-code tools evaluate the plan, not just the source, as the authoritative point to check against before anything is provisioned.
Why would you use a NAT gateway instead of just putting a resource in a public subnet?
A NAT gateway lets resources in a private subnet initiate outbound connections to the internet (to pull a package, call an external API) while remaining unreachable from the internet for inbound connections; the NAT gateway only translates and forwards traffic the private resource itself initiated. Putting a resource directly in a public subnet with a public IP makes it directly reachable from the internet in both directions, which is unnecessary exposure for anything that only needs outbound access, like an application server that doesn't need to accept direct public traffic.
What's the practical difference between Repeatable Read and Serializable, given that PostgreSQL's Repeatable Read already prevents phantom reads?
PostgreSQL's Repeatable Read goes beyond the SQL standard's minimum and already prevents phantom reads via snapshot isolation, but it can still allow a specific class of anomaly called a serialization anomaly, where the combined effect of several concurrently-committed transactions is not equivalent to any possible serial (one-at-a-time) ordering of them, even though each transaction individually looks consistent. Serializable adds predicate locking on top of snapshot isolation specifically to detect and prevent that remaining anomaly, guaranteeing that the outcome is always equivalent to transactions having run one at a time in some order. The cost is the same as Repeatable Read's, more serialization failures the application must retry, in exchange for the strongest correctness guarantee available.
A component's state is preserved when a prop changes, but reset when a completely different element renders in the same spot. What determines which happens?
React associates state with a component's position in the render tree, not with the component instance or its props specifically. If the same component type renders at the same tree position across a re-render, its state is preserved regardless of what props changed. If a different component type (or a different element entirely) renders at that same position, React treats it as a genuinely different thing, destroys the old state, and starts fresh. This is why toggling a prop on the same `<Counter />` keeps its count, but swapping `<Counter />` for a `<p>` at that same spot in the tree resets it entirely, even though from the JSX it might look like a small, local change.
If a microtask itself queues another microtask while it's running, does that new microtask wait for the next event loop iteration, or does it still run before the next macrotask?
It still runs before the next macrotask. The rule isn't "run the microtasks that were queued when this iteration started", it's "drain the microtask queue completely," and if executing a microtask adds another one, that new one is still part of the queue being drained. This means a chain of microtasks that keep scheduling more microtasks can, in principle, starve the event loop from ever reaching the next macrotask (a real, documented way to accidentally block timers and rendering), which is different from a single flat batch of microtasks all queued up front.
How does a Network Security Group (NSG) evaluate traffic rules?
An NSG contains a prioritized list of allow/deny rules, evaluated in priority order (lowest number first) until the first rule matching the traffic's source, destination, port, and protocol is found, that rule's action wins, and no further rules are evaluated. NSGs can attach to a subnet, a network interface, or both, and are stateful, meaning an allowed inbound connection's return traffic is automatically permitted without needing a matching outbound rule. Because evaluation stops at first match, rule priority ordering is the actual logic, a broad allow rule placed before a specific deny rule silently makes that deny unreachable.
Why does a naive `hash(key) % N` scheme for distributing keys across N servers fall apart the moment a server is added or removed?
With plain modulo hashing, the server a key maps to depends directly on the current value of N, since almost every key's `hash(key) % N` result changes the instant N changes to N-1 or N+1, even though the underlying hash values themselves didn't change at all. That means adding or removing a single server can remap the overwhelming majority of keys to different servers simultaneously, which for a cache means a massive wave of cache misses, and for a sharded store means a massive, unnecessary data-migration event, triggered by a change to just one server out of many.
Why does string escaping alone not fully prevent SQL injection?
Escaping tries to neutralize special characters (like quotes) so user input cannot break out of its intended string literal, but it is easy to get wrong, different databases and contexts (string literals, numeric contexts, identifiers, LIKE patterns) have different escaping rules, and a single missed case reopens the vulnerability. Parameterized queries avoid the problem entirely: user input is sent to the database separately from the query structure, so it can never be interpreted as SQL syntax regardless of its content.
A custom dropdown built entirely from styled divs passes a visual design review. What is likely still broken for a keyboard-only or screen-reader user, and why doesn't looking right catch it?
Without the correct ARIA roles/states (or, better, a native `<select>`), a div-based dropdown typically has no way to be reached or operated via keyboard alone (no built-in Tab/Enter/Arrow-key handling), and a screen reader has no semantic information telling it "this is a dropdown, it is currently closed, here are its options," so it may announce nothing meaningful at all. A purely visual review can't catch this because the div looks and behaves correctly with a mouse, the missing behavior only surfaces via keyboard navigation or assistive technology, which is exactly why accessibility has to be tested directly with a keyboard and a screen reader, not inferred from how a component looks.
Mastering Nano, Vim & NeoVim on Linux: From Beginner Editing to Pro-Level Terminal Workflows
Nano vs Vim vs Neovim: Which Linux Text Editor Should Engineers Actually Use?
When does semantic search (via embeddings) actually outperform traditional keyword search, and when might keyword search still win?
Semantic search wins when a query and the relevant document use different words for the same idea, "car won't start" matching a document about "vehicle fails to ignite", since embeddings compare meaning rather than literal tokens, which keyword search cannot do at all. Keyword search still wins, or at least remains necessary, for exact-match needs, an error code, a product SKU, a specific proper noun, where the literal string matters and a semantically "close" but textually different result is actually the wrong answer. This is why production search systems commonly combine both (hybrid search) rather than treating embeddings as a strict replacement for keyword matching.
According to OWASP SAMM, what should happen at the highest maturity level when a security check fails during the build?
At the highest build-process maturity level, organizations define mandatory security checks and ensure that building a non-compliant artifact actually fails, the pipeline is configured to stop, not just record a finding for someone to look at later. This is the difference between security scanning that genuinely gates what gets shipped and scanning that only produces a report nobody acts on; a finding that doesn't block the build in practice functions as a suggestion, not a control.
What is layout thrashing, and why does writing then reading a layout property in a loop specifically cause it?
Layout thrashing happens when code alternates writing a style (which invalidates the current layout) and reading a layout-dependent property like `offsetWidth` (which forces the browser to immediately recalculate layout synchronously to answer that read accurately), repeated across many elements in a loop. Each read-after-write pair forces a fresh, synchronous layout recalculation instead of letting the browser batch and defer that work to its normal rendering schedule, because the code demanded an up-to-date value mid-loop. The fix is mechanical: batch every write first, then batch every read afterward, so layout is only recalculated once instead of once per element.
Why does publishing a port with -p 8080:80 not automatically make the container reachable from other containers?
-p (or --publish) maps a port on the Docker host to a port inside the container, specifically for reaching the container from outside the Docker network, from the host machine or the internet. Other containers on the same user-defined network do not need that mapping at all; they can reach the container directly on its internal port via the container's name and internal port, because they share the internal bridge network. Publishing a port is about host-to-container access, not container-to-container access.
What does NIST's own definition of dynamic programming actually say the technique does, and what problem does it solve?
NIST's Dictionary of Algorithms and Data Structures defines dynamic programming as an algorithmic technique to "solve an optimization problem by caching subproblem solutions (memoization) rather than recomputing them." The problem it solves is redundant recomputation: when a naive recursive solution calls itself with the same subproblem arguments repeatedly (matrix-chain multiplication, longest common subsequence, and similar problems are the examples NIST gives), that same subproblem gets solved from scratch every single time it recurs, and caching the first result lets every later occurrence be a lookup instead of a full recomputation.
What is the difference between `git reset` and `git revert`, and when should you use each?
git reset moves the current branch pointer (and optionally the staging area and working directory) to a different commit, effectively rewriting history as if the reset-past commits never happened on this branch - fine for commits that only exist locally and haven't been pushed. git revert creates a brand new commit that applies the inverse of a previous commit's changes, leaving history intact and additive. Because it doesn't rewrite anything, revert is the safe choice for undoing a commit that's already been pushed and pulled by others; reset --hard on shared history causes exactly the same divergence problem as a rebase on a shared branch.
What is the required contract between equality and hashing for an object used as a dictionary key, and why does the hash table need it specifically?
The contract is one-directional but strict: if two objects compare equal, they must produce the same hash value. A hash table uses an object's hash to pick which bucket to look in, then uses equality only to confirm the exact match within that bucket, so if two equal objects hashed differently, a lookup for one would search the wrong bucket entirely and never even reach the equality check that would have confirmed the match. The hash doesn't have to be unique across unequal objects (collisions are expected and handled), it just has to agree for anything that compares equal, that's the one property the whole lookup mechanism depends on.
A request's input already exceeds the model's context window before generation even starts. What happens, versus a request that only exceeds the limit once output is generated?
If the input alone already exceeds the context window, the API rejects the request upfront with a 400 error, generation never starts at all. If the input fits but input tokens plus the requested max output tokens could exceed the window, current models accept the request and generate as far as they can; if generation actually reaches the window limit before finishing, it stops early with a specific stop reason indicating the context window was exhausted, rather than silently truncating or erroring out mid-response. The distinction matters operationally: the first case is a fixable request-construction bug, the second is a signal to reduce the requested output length or the accumulated conversation history.
Why would a system use a sliding window rate limiter instead of a token bucket, and what problem does it fix?
A naive fixed window (say, "100 requests per minute, resetting on the minute") allows a client to send 100 requests in the last second of one window and another 100 in the first second of the next, 200 requests in a two-second span despite the stated 100/minute limit, an artifact of the window boundary rather than actual demand. A sliding window rate limiter instead evaluates the limit over a continuously moving time range rather than fixed, discrete buckets, which avoids that boundary-doubling effect at the cost of typically more state to track (timestamps of recent requests, not just a single counter) compared to a token bucket's simpler accumulator model.
Why does using an array index as a list item's key cause state to attach to the wrong item once the list is reordered, and what's the fix?
With `key={i}`, React tracks each item's state by its position in the array, not by which real-world item it represents, so after reversing a list, the state that was originally at index 0 (say, an "expanded" toggle on the first item) stays at index 0 and now renders alongside whatever item ended up there after the reorder, not the original item it belonged to. The fix is using a stable, unique identifier from the actual data, `key={contact.id}`, so React can match each item to its correct state across renders regardless of how the list is reordered, added to, or filtered, rather than relying on a position that can shift under the data.