Inside htop you have found a misbehaving process and want to signal it without leaving the interface. Explain what F9 does, how tagging rows with Space changes the target set, and what can go wrong when htop's thread display is switched on.

## The kill panel Pressing F9 (or the `k` shortcut) in htop opens a panel listing the available signals by name and number, with **SIGTERM preselected**. You move through the list, press Enter, and htop issues the signal. Nothing else about the interface changes: there is no second confirmation dialogue, and no undo. That is the whole feature, and its convenience is exactly what makes it worth understanding precisely before you use it on a production host. SIGTERM is the default for the same reason it is the default of the `kill` command: it is the polite request, and a well-behaved program uses it to finish in-flight work, flush state and exit. Escalating to SIGKILL is a decision to give up on that cleanup, and it should be a deliberate second step after the first one visibly failed, not the reflex first keystroke. ## Selection versus tagging htop has two different notions of "the target": - **The cursor.** With no rows tagged, F9 acts on the single highlighted row. - **The tag set.** Space toggles a tag on the current row; tagged rows are highlighted differently. As soon as anything is tagged, F9 acts on **every tagged row** and ignores the cursor. `U` untags everything. Tagging is genuinely useful — filter to a worker pool, tag the stuck ones, signal them in one action instead of hunting PIDs one at a time. It is also the most common way to do something you did not intend, for two reasons. First, a tag is attached to the process, not to a screen position, so it survives sorting, filtering, scrolling and refreshes; you can tag three rows, change the filter, forget them, and later signal a set that includes processes that are not currently on screen. Second, nothing on the kill panel tells you how many processes are about to receive the signal. The discipline is simple: press `U` before you start selecting, and glance over the tagged rows immediately before pressing F9. ## Permissions htop performs no privilege magic. The signal goes through the same kernel check as any other sender: an unprivileged user may only signal processes with a matching user ID, and anything else fails with `EPERM`, which htop surfaces as an error. Running htop as root removes the refusal — and removes the last thing standing between a mistyped cursor position and a signalled database. ## The thread-display trap `H` toggles the display of user threads. With it on, a multithreaded server that occupied one row now occupies dozens: one per thread, each showing its thread ID in the PID column and rendered in a different colour. It is a useful view — you can see which thread is burning CPU — but it changes what the rows *mean*, and htop's kill panel behaves the same way regardless. The kernel's `kill` interface delivers a signal to a **thread group**, that is, to the whole process. Selecting the one hot thread and sending it SIGKILL does not surgically remove that thread; it terminates the entire process, all of its threads with it. There is no "kill one thread" operation available here at all, so anyone who reaches for one has misunderstood the view. The same caution applies to `K`, which shows kernel threads — rows you should be reading and never signalling. ## When F9 is the wrong tool entirely If the process belongs to a supervised service, signalling its PID from a process viewer routes around the supervisor. The service manager sees an unexpected death, applies whatever restart policy the unit carries, and the thing you just killed may be back before you have finished reading the screen — or worse, the main process dies while helper processes it started keep running. Stop supervised services through their service manager, where the state transition, the dependent units and the logging are all handled coherently. Reserve F9 for the genuinely unmanaged process: the runaway script, the orphaned import job, the developer's forgotten test harness. A reasonable habit on production hosts: use htop to *find* the process, note its PID and full command line, then issue the signal as an explicit command you can read back before pressing Enter, or through the service manager. The interactive path is fastest, and speed is not what you want from a destructive action taken at three in the morning.