Threads and processes

Task Manager shows what is running on the machine now: every process, which is a program that is running, with how much of the processor and memory it is using, what it belongs to, and who it runs as. What is defined to run, rather than what is running, is Services Manager's.

Start it from the launcher: Task Manager.

It looks at the machine as you, so it shows exactly what you may see of each process, and says what you may not, and why. It offers to change something only where you may.

Processes, Performance, Jobs and Signed in, in the bar, switch between its four views.

Find the right process before acting #

1. Open Processes. Use Find for a name, PID, person or service, or sort CPU or Memory to investigate resource use.
2. Select the process. Check its command, who it runs as, what started it, and the service or job it belongs to. Some details may be hidden by permissions.
3. Choose the scope of the action. To stop a service and everything it started, use Stop service; to stop a submitted job, use Stop job. Use End process when you intend to end only that process.
4. Read the confirmation and refresh the view to check the result. Ending a service's main process may cause peinit to restart it.

A process is one running program. A service is a persistent definition managed by peinit, and can start a new process after the old one ends. A submitted job is work someone asked peinit to run and watch. For those managed lifetimes, see Services and jobs. For process states and terminal signals, see Process lifecycle.

The processes #

Each process is listed with its name, its PID (the number the system knows it by while it runs), who it runs as, and its share of the processor (CPU) and the memory it holds. The CPU share is of the whole machine, since the last look, and is filled in from the second look on. The bar at the bottom gives the totals.

Group by chooses how they are arranged:

• None, which it opens with, lists them all together.
• Service puts each process under the service or job it belongs to, as peinit, the service manager, started it. A service's heading says its state; a job, which is a program someone asked peinit to run and watch, such as a person's desktop session, says who it runs as. Not in a service holds peinit itself.
• Person puts each under the person or service it runs as.

Name, PID, CPU and Memory, at the top of the list, sort by that. Find narrows the list to processes whose name, PID, person or service contains what you type.

The kernel's own threads, which no person runs, are left out; tick Kernel threads to show them.

The list is read again every two seconds. Refresh, or F5, reads it at once.

A process in full #

Select a process to see it in full on the right: what it is doing, how long it has run, its CPU, memory and threads, what started it (select it to go to it), the command it was started with, the service or job it belongs to and which part of it this is, who it runs as, the signed-in session it is part of, and its integrity.

Protection says whether the process is protected: signed as part of Peios, which closes it to every process not signed at its level, however much authority that process has. Mitigations are the hardening the process runs with, such as no memory being both writable and executable, each with what it does. See The process security block.

Ending a process, or stopping its service or job #

Below a process's details are what you may do to it:

• End process asks first, then asks the process to end. One that hasn't ended after five seconds is offered End it now, which ends it at once, without its finishing what it is doing. The process is held onto from the moment you ask, so another process given the same PID later can't be ended by mistake.
• Stop service, for a process that belongs to a service, asks peinit to stop the service, and everything it started. It stays stopped until it is started again. Ending a service's main process instead counts, to peinit, as the service crashing, and it may start it again; the window says so before you do.
• Stop job, for a process in a job, asks peinit to stop the job.

Each is there only where you may do it: End process where the process's permissions let you end it, and Stop where peinit says you may stop that service or job. Where you may not, the pane says why instead. A protected process can't be ended by any program not signed at its level.

Performance #

Performance shows the machine as a whole: how busy its processors are, how much of its memory is in use, and how fast each disk and network interface is moving data. Each is listed down the side with a small graph; select one to see it in full, with a graph of the last two minutes, newest at the right.

• CPU graphs how much of the processors' time is in use, and how much of that is the kernel's own work. Each processor gives each logical processor a graph of its own. Below are the processor's model and speed, the number of processes and threads, how long the machine has been up, and the load average: how many threads were running or waiting to, on average over the last 1, 5 and 15 minutes.
• Memory graphs how much is in use, and shows what all of it is made of: in use, cache the kernel gives back when programs need it, and free. Available is what programs could be given now. Committed is what programs have been promised, against how much may be.
• Each disk graphs how much of the time it was busy (its active time), and how fast it read and wrote. Its capacity, and what it has read and written since the machine started, are below.
• Each network interface graphs how fast it is receiving and sending, in bits a second as networks are measured. Its state, link speed and hardware address are below; its addresses and settings are Network Manager's.

The figures are the kernel's own, which anyone may read, so everyone sees the same view. Speeds are worked out between one look and the next, every two seconds. Nothing is kept once the window closes.

Jobs #

A job is a program someone asked peinit to run and watch, outside any service: a person's desktop session is one. Jobs lists them: what each is, its state, who it runs as, and how far it says it has got. A job in full shows what it last said of itself, its progress, its program and process, who it runs as and who asked for it, when it started and ended, and how it ended. Stop job is there where you may stop it.

peinit lists a job only to those who may see it: by default, whoever asked for it, and Administrators. The others are left out, and the window says so. A job that has ended stays in the list for a minute.

Who is signed in #

Signed in lists each session, which is one sign-in: who, how (at the machine, on the desktop, over SSH, or over the network), since when, and how many of its processes you can see. A session in full lists its processes, each of which leads to it, and its desktop session, if it has one. Services sign in too, each in a session of its own; tick Services' sessions to show them.

The full list is the kernel's, which only Administrators may read. Anyone else sees the sessions their own processes are in, and the window says so.

Signing someone out #

Sign out, in a session's details, ends the session: authd ends every process running in it, asking each to end and, after a few seconds, ending any that haven't. The window asks first, and says so when the session is its own. What came of it is said afterwards, including any process authd couldn't end, which keeps the session open.

You may sign out your own sessions, and anyone's the machine's permissions allow, which as shipped is Administrators. Where you may not, the window says why. A service's session ends when its service is stopped, and the kernel's own sessions never end. See Ending a session.

What you may see #

What you may see of a process is its own permissions' to say:

• Its name, CPU, memory and what it belongs to are visible to everyone, by default.
• Who it runs as, and the command it was started with, are visible to the person it runs as and to Administrators. Anyone else sees the process without them, and a note above the list says how many processes that is.
• A protected process, such as peinit or authd, is closed to everyone, Administrators included: only processes signed at its level may look into it. It is still listed, with its protection, and a note above the list says how many there are. Where peinit can say which service a protected process is, it is listed under that service.

A process in a job you may not see is listed under A job, and says so.

In a terminal #

The toolset documented here does not yet include ps; use Task Manager for the process list. The documented terminal tools cover these narrower tasks; replace PID, NAME and ID with the process, service or job/session you have checked.

The same access restrictions apply to terminal tools. logonse list can show only a partial view; a missing entry is not proof that nothing is running. Read Controlling services for service and job commands, and End, suspend, or resume a process before sending signals.

To see what is running, open Task Manager from the launcher. Find a process by name or PID, check its CPU and memory, and select it to see who it runs as and which service or job it belongs to. Start with the Task Manager guide for the controls and the limits on what you can see.

A process is a running program, together with its memory, open resources, and the state the system keeps for it. A thread is one line of execution inside that process. Every process starts with one thread and can create more; its threads share memory and open resources while each makes progress through its own work.

The actors of the system #

Every action, such as opening a file or sending data, is performed by a thread. The system checks whether that thread is allowed and records which thread acted. Each thread acts as a person, a service, or the system itself; there is no "nobody" state. Its token carries that identity, and a new child process begins with its parent's identity.

The thing to stop depends on what you want to achieve:

A service is a persistent definition; a process is one thing running now. A submitted job is work someone asked peinit to run and watch. A terminal's job-control group is another use of "job", described in Process relationships and job control.

What a process has #

The PID identifies a process while it exists and can be reused afterwards. The Process GUID identifies that one process permanently. Neither tells you who it runs as. For a lasting event record, use the GUID; before acting on a PID, check the current process again.

The Process Security Block (PSB) holds the GUID, protection, hardening and the process's own permissions. Being able to see a process does not mean you may stop or inspect all of it.

Where to start #

• Task Manager: find a process, investigate resource use, and choose a process, service, or job action.
• Process lifecycle: interpret states and safely end, suspend, or resume a process.
• The process and thread model: understand threads, PIDs, GUIDs, and identity.
• Creating processes: understand why starting a program adds a process, and why a process can change programs.
• Process relationships and job control: understand parents, terminal process groups, and sessions.
• The Process Security Block: understand protection and access refusals.

The syscall and threading-library contracts are in the developer Process runtime reference.

A process row in Task Manager represents a running program; its thread count tells you how many lines of execution it contains. Use the PID to find it now, the Process GUID to match historical records, and its token identity to understand who it runs as.

A running program has two separable parts: the threads, which run, and the process, which contains them.

The thread is the part that runs — one line of execution, a single sequence of steps the system works through. A machine with several cores runs that many threads genuinely in parallel, one per core; a single core runs many threads by switching between them. Which thread runs, on which core, and for how long is decided by the system's scheduler — a subject of its own. Some tools and logs call a thread a task; it is the same thing.

The process is the boundary around a group of threads. It does not run — it contains. A process holds the things its threads share: their private memory, their open files and connections, and their identity. Every thread inside one process sees the same memory and the same open resources; threads in two different processes do not. That separation is what stops one program from reaching into another's memory or files.

The thread does the work; the process is the shared space the work happens in. A program that does one thing at a time is a process with a single thread. A program that does several things at once is a process with several threads, all sharing one space.

Why the thread is the more basic idea #

Threads, not processes, are the fundamental unit: what the system runs is threads, and a "process" is the answer to the question "what does this thread share, and with whom?" Bundle some threads together so they share one memory, one set of open resources, and one identity, and that bundle is a process. Give a thread its own fresh, separate memory instead of sharing an existing one, and you have made a new process.

This matters because it explains creation. Making a new thread and making a new process are the same mechanism with a different answer to "how much does the new line of execution share with the one that made it?" Share everything, and the result is another thread in the same process. Share nothing, and the result is a new process. Everything in between is possible too. How the operation is actually performed is covered in Creating processes.

What threads share, and what they don't #

Within one process, every thread shares:

Each thread keeps its own place in its sequence — which step it is on right now. That is the point of having more than one: each thread makes progress through its own work independently of the others.

There is one exception to the shared identity. A single thread can temporarily act as a different principal — for example, a service handling a request can act as the requester for that one piece of work, then revert. Only that one thread is affected, and only until it reverts. This is covered in Impersonation; here it is enough to know that "every thread in a process shares the process's identity" is the default, not an unbreakable rule.

Naming a process #

The system gives each process a number called its process ID, or PID, so that people and other programs can refer to it — to inspect it, signal it, or wait for it to finish. Threads are individually identifiable too, by a thread ID — see the developer thread operations reference.

A PID is short and convenient, but it only names a process while that process exists. Once a process ends, its PID can later be reused for a completely different process. A PID tells you which process is which right now, but it is useless as a lasting record — two unrelated processes can hold the same PID at different times.

For that, every process also has a Process GUID (globally unique identifier): a name that is never reused, assigned to each process when it starts and fixed for the rest of its life. Where the PID is the convenient short handle for the moment, the Process GUID is the permanent one — it identifies that one specific process and no other, even long after it has ended. This is what lets a record of something that happened on the system name exactly the right process, with no chance of confusing two that happened to share a PID.

Both the PID and the GUID refer to a process. Neither says who the process is acting as — that is a separate question, answered by its identity rather than by any number or name.

Where to go next #

For interpreting a state or safely sending a signal, continue with Process lifecycle. To understand what a new program starts with, read Creating processes.

Starting a command or application can create new processes. In Task Manager, select one to see its parent, command and service or job. A new process gets a new PID and Process GUID, but a running process can also change the program it runs without changing either identifier.

These two cases explain most changes you see in the process list. You do not need to call the creation APIs to start an application from the launcher or run a command in a terminal.

Splitting: one process becomes two #

A running process can create a near-copy of itself. The original is the parent; the new process is its child. This is called fork.

The child gets private memory copied from the parent, copies of its open resources, and the same identity. Changes to one process's private memory do not change the other's. The child has its own PID and Process GUID, and some per-process state starts fresh. Identity inheritance is covered in Token lifecycle; the precise inheritance list is in the developer creation reference.

Replacing: same process, different program #

A process can replace its current program with another, called exec. Its PID and Process GUID stay the same, and it retains its identity; the previous program's memory and code are replaced. A changed program name therefore does not by itself mean a different process has taken over that PID.

For the identity rules, including programs marked to run as another principal, see Token lifecycle. The exact preserved and reset state is in The exec family.

Putting them together #

Launching a new program commonly combines the two steps: create a child, then replace the child's program. Spawn combines this pattern for callers. Thread creation uses the same underlying creation mechanism with resources shared instead of private; the general mechanism is called clone.

For operating the system, check the resulting process and what manages it. If a service keeps creating replacement processes, inspect the service's status and supervision policy, rather than repeatedly ending each new PID. API details belong in the developer process creation reference.

Getting hold of the new process #

A PID can be reused after a process ends. Recheck the current name, command, owner and service or job before signalling a PID from a terminal, especially if it came from an old log or an earlier inspection.

Programs can hold a pidfd, a file-descriptor handle tied to one specific process, obtained at creation or for a process that already exists. Unlike a bare PID, that handle cannot later refer to a different process; it can be used to wait for the process or signal it. Task Manager holds onto the process from the moment you ask to end it, protecting that action against PID reuse. For code that needs this guarantee, see Process handles.

Where to go next #

Process lifecycle explains states, termination, and cleanup. If you are implementing a launcher or threading library, use the developer Process runtime reference.

Read a process's state before deciding what to do. A sleeping process can be healthy, a stopped process is paused rather than finished, and a zombie has already ended. Use Task Manager to check the process, its parent, and whether a service or job manages it.

The states it passes through #

While it exists, a process is in one of a handful of states, and the system moves it between them. Most of the time it is either running — executing, or ready to run the moment a core is free — or sleeping, paused while it waits for something to happen, such as data to arrive or a timer to fire. A sleeping process uses no processor time until what it is waiting for is ready; most processes spend most of their lives asleep.

A few states are worth knowing by name:

• Stopped — suspended (for example by job control when a job is paused at the terminal); it does nothing until told to resume.
• Traced — stopped under the control of a debugger that has attached to it, so the debugger can inspect and step it.
• Uninterruptible sleep — waiting on something the system will not interrupt, almost always a brief piece of disk or device I/O. A process here cannot be woken or even killed until the operation finishes; it normally lasts an instant, and a process stuck in it is a sign that hardware or a filesystem is stuck too.
• Zombie — finished, but still held as a result waiting to be collected (see below).

Once its result has been collected the process is gone, removed from the system entirely.

End, suspend, or resume a process #

First check the scope. Stop service or svctl stop NAME asks peinit to stop a service and its processes; Stop job or svctl job stop ID stops a submitted job. Ending a service's main process directly can count as a crash and trigger a restart. See Controlling services.

For one process, Task Manager's End process asks it to end, then offers End it now after five seconds if it is still there. The immediate option does not let the program finish its work. Task Manager holds the process so a reused PID cannot redirect that action.

From a terminal, use kill. Replace 4821 in these examples with the PID you have just checked:

$ kill 4821                 # send TERM: ask the process to terminate

Give it time to finish, then refresh Task Manager and check the result. Only if TERM has failed, and losing unfinished work is acceptable, consider:

$ kill -KILL 4821           # force termination without application cleanup

To pause a process and later let it continue, use the documented stop and continue signals:

$ kill -STOP 4821           # suspend
$ kill -CONT 4821           # resume

Suspension is not completion: the process does no work until resumed. Check that pausing it will not interrupt work other programs or people depend on. This targets one process, not a whole service or terminal pipeline.

TERM and KILL require permission to terminate the process; STOP and CONT require permission to suspend or resume it. Protected processes also require sufficient program trust. Being an administrator or sharing a terminal session does not bypass protection. See Process permissions.

A successful kill exit status means the signal was sent, not that the process has finished. Exit status 1 means a signal could not be sent, for example because the process no longer exists or you may not signal it. Check the refreshed process or managed-service/job status before declaring it stopped.

Two ways a process ends #

A process ends in one of two ways.

Most often it ends on its own: it finishes its work and stops. A process that ends this way leaves behind an exit status — a small record of how it went, usually just "succeeded" or "failed" (and, on failure, a number giving a rough reason). The act of a process ending itself is called exit.

The other way is that a process is ended by a signal from outside. Its exit status records the terminating signal. This is different from the stopped state above, which means suspended and able to resume.

Either way, a record of the process remains until its result is collected.

Collecting the result #

Whenever a child changes state — ends, is stopped, or resumes — the system sends its parent a signal, SIGCHLD, prompting it to check. The parent then reads the child's exit status. This is called waiting for the process.

Between the moment a process ends and the moment its parent collects the result, the finished process is a zombie: no longer running, but with the system still holding its exit status so the parent can read it. Despite the name, a zombie is harmless — it does no work and uses almost nothing; it is a result waiting to be collected. The instant the parent collects it, the zombie is gone for good.

If a parent never collects, zombies accumulate — finished processes whose results no one read. That is a fault in the parent, not normal behaviour. Inspect the parent and its service or job; a zombie has already finished, so sending it another termination signal does not make the parent collect it.

A parent holding a pidfd for its child can wait on it directly — the dependable way to be told the exact moment the child ends.

The exact calls — every wait variant, and how an exit status is read — are in the developer process lifecycle reference.

When the parent ends first #

A parent does not always outlive its children. If a parent ends while one of its children is still running, that child becomes an orphan.

Orphans are adopted automatically, and keep running with a new parent. The system's first process — PID 1, which on Peios is peinit — is the final adopter when no nearer subreaper takes responsibility. When the adopted child ends, its new parent collects the result.

PID 1 is the catch-all. A subreaper can instead adopt orphaned descendants within its own subtree; service and container managers use this to retain responsibility for the work they launched. For the programmatic contract, see Orphan adoption and subreapers.

What the system cleans up #

When a process ends, the system reclaims what it was using. Its private memory is freed and its open files and connections are closed.

It also releases its identity. A process acts as a principal, carried on its token; when the process ends, its hold on that token is released. If other processes were sharing the same identity — for example, siblings from the same login — the identity lives on for them, and the system clears it away only once nothing is using it any more. The details are in Token lifecycle.

The process's PID becomes available for the system to assign to a future process. Its Process GUID is not reused — it remains a permanent marker of that one process, so records of what it did still point unambiguously back to it long after it is gone.

Where to go next #

Processes are arranged into a family tree and grouped together in ways that matter for running them. That is Process relationships and job control.

Use a process's parent to trace what started it. Use its service or submitted job to choose a managed stop. At a terminal, use the process group to understand which commands receive keyboard signals together. These are different relationships; stopping one PID need not stop all the work it belongs to.

Processes are related by descent, forming a family tree, and by grouping, which lets terminal job control handle several together.

The family tree #

Every process was started by another, so every process has a parent: the process that created it. A process can refer to its parent by the parent's PID, sometimes called the PPID (parent process ID).

Follow the parents upward and they all lead back to the same place — PID 1, the first process, which the system starts at boot. Every other process descends from it, directly or through a chain of parents, so the processes on a running system form a single family tree rooted at PID 1. This is the same tree that makes orphan adoption work: when a process loses its parent, PID 1 takes over the role, as covered in the lifecycle.

A few processes at the very root of the tree are special. PID 1 is the first process started at boot — on Peios, peinit — and the ancestor of all the rest; the system protects it, refusing to kill it with any signal it has not chosen to handle, because losing it would bring down the whole tree. Beneath the userspace processes the kernel runs threads of its own: PID 0 is the idle process (what a core runs when it has nothing else to do), and PID 2, kthreadd, is the parent of every kernel thread. The kernel's threads — among them the worker threads (kworker) that run deferred work and the threads that service hardware interrupts — appear in a process listing as the system's own work rather than as programs loaded from disk.

Process groups #

Several processes often do one job together. In a pipeline — the output of one command feeding into the next — each command is its own process, but they form one job: you stop, pause, or resume the whole job at once, not a piece at a time.

To make that possible, related processes are collected into a process group. A process group is a set of processes treated as a unit, so that an action — most often a signal, like the one that stops a job — can be delivered to all of them together instead of one by one.

A terminal job, such as a pipeline, is not the same thing as a submitted job watched by peinit. Task Manager's Jobs view and svctl job operate on submitted jobs; terminal job control operates on process groups. See Jobs and operations.

Sessions and the terminal #

Process groups are themselves collected into a larger unit: a session, tied to the terminal the work is running at.

A terminal can only take input for one job at a time, so within the session one process group is the foreground group: the one connected to the keyboard, the one typing reaches, the one a stop-or-interrupt keystroke acts on. Any other groups are in the background, running without holding the keyboard. Moving a job between foreground and background — and starting, stopping, and resuming jobs — is job control.

Ctrl-C sends the terminal's interrupt signal to the foreground process group; Ctrl-Z sends its stop signal. A command such as kill -STOP PID targets the named process instead. Resume that process with kill -CONT PID when permitted; see suspending and resuming. Keyboard signals and explicit kill commands take different permission paths, as explained in Signals in detail.

A different kind of "session" #

The word "session" has two meanings here, and they are unrelated:

• A job-control session, described above, organises processes at a terminal — which groups share a terminal, which one is in the foreground. It says nothing about who anyone is.
• A logon session records one sign-in — a single authentication event — and ties together every identity token that came from it. It is part of the identity model, covered in Logon sessions.

They often line up in practice — signing in at a terminal creates a logon session, and the processes run there share a job-control session — but they are separate things answering separate questions: "which processes share this terminal?" versus "where did this identity come from?"

Where to go next #

Beyond its place in the tree and its groups, every process carries a bundle of its security-related settings — its Process Security Block. That is The Process Security Block.

When Task Manager hides details or refuses End process, inspect the process's Protection and Mitigations. In a terminal, logonse psb --pid PID shows its protection, hardening and Process GUID without changing them.

A process's identity — who it is acting as — is carried on its token, and can change moment to moment, since a thread can impersonate another principal. A process has a second aspect that is independent of identity: what it is. What program is it running? How trusted is that program? How hardened is it against attack? Who is allowed to operate on it?

Those facts are gathered in one place — the Process Security Block, or PSB. Every process has one. Where the token answers who this process is acting as, the PSB answers what this process is. Unlike the token, the PSB never changes when a thread impersonates: impersonation changes who, never what.

What the PSB holds #

• Its permanent name. The process's Process GUID — the never-reused identifier — lives on the PSB.
• How trusted its program is. When a process starts running its program, the system checks the program's cryptographic signature and records from it how trusted the program is. This is the process's PIP (Process Integrity Protection) label, and it decides which other processes are allowed to inspect, signal, or interfere with this one. The barrier is based on what program is running, not on who is running it: even a fully privileged process cannot disturb a more-trusted one. The full treatment is Process integrity protection.
• How it is hardened. A set of mitigations — restrictions the process carries on what it may do with its own memory and code, so that a bug or injected code has far less room to do harm. They can only ever be tightened, never loosened. The catalog and rules are Process mitigations.
• Who may operate on it. Every process has its own security descriptor — the rules for who is allowed to act on the process itself: inspect it, signal it, and so on. It lives on the PSB alongside the rest.

A few more specialised settings live here too — a process can be marked so that it may no longer create children, for instance — but those four are the core.

Inspecting and managing the PSB #

A process's PSB can be read by anyone the process's permissions let see its name and CPU use, which by default is everyone — even where the process is protected and nothing else about it can be seen. That is what lets a tool say why a process is closed to you.

• On a terminal, logonse psb --pid PID shows a process's protection, mitigations and GUID, and with --mitigations turns mitigations on.
• On the desktop, Task Manager shows them for the process you pick.
• From a program, read /proc/<pid>/psb, or call peios_process_psb in the SDK.

When an action is refused #

Being able to see a process's name or PSB does not grant control of it. Its security descriptor determines which actions your identity may perform. Signals also have to pass Process Integrity Protection (PIP): the program sending the signal must have enough trust to act on the target.

The PSB inspection surface does not require PIP dominance, which is why a tool can explain that a process is protected even when its other details are closed. Detailed inspection and signalling still require it. Even SeDebugPrivilege does not bypass PIP, and impersonating a different identity does not change the calling program's trust.

For a managed service, use Stop service or svctl stop NAME when permitted. That asks peinit to perform the managed action under the service's own permissions, instead of trying to signal its protected process directly. See Who can manage a service.

Before changing mitigations #

logonse psb --pid PID is an inspection command. Adding --mitigations MASK changes hardening: those flags can only be turned on, never cleared during the process's lifetime. Check the mitigation rules and the logonse reference before using that option. It is not a way to gain permission to inspect or end the process.

Where to go next #

The two largest parts of the PSB each have a topic of their own: Process integrity protection, for the trust label that governs which processes may interfere with which, and Process mitigations, for the self-hardening flags and how they are applied.