MidnightBSD: The BSD For Everyone

Processes and Daemons

Processes and Daemons

Introduction

MidnightBSD is a multi-tasking operating system. Each program running at any one time is called a process. Every running command starts at least one new process and there are a number of system processes that are run by MidnightBSD itself.

Each process is uniquely identified by a number called a process ID (PID). Similar to files, each process has one owner and group, and the owner and group permissions are used to determine which files and devices the process can open. Most processes also have a parent process that started them. For example, the shell is a process, and any command started in the shell is a process that has the shell as its parent process. The exception is a special process called init(8), which is always the first process to start at boot time and which always has a PID of 1. All other processes on the system are ultimately descendants of init.

PIDs are assigned starting at 1, increase up to 99999, then wrap around. A PID is not reassigned if it is already in use. Each process also has a parent PID (PPID) identifying the process that created it. When a parent process exits before its children, the children are re-parented to init.

Daemons

Some programs are not designed to be run with continuous user input and disconnect from the terminal at the first opportunity. For example, a web server responds to web requests rather than user input. Mail servers are another example of this type of application. These types of programs are known as daemons. The term daemon comes from Greek mythology and represents an entity that is neither good nor evil, and which invisibly performs useful tasks. This is why the BSD mascot is a daemon with sneakers and a pitchfork.

There is a convention to name programs that normally run as daemons with a trailing "d". For example, BIND is the Berkeley Internet Name Domain, but the actual program that executes is named named. The Apache web server program is httpd and the SSH server is sshd. This is only a naming convention — the main daemon for the Sendmail application is sendmail, not maild.

Daemons typically start at boot time, run as a dedicated system user with limited privileges, write logs to /var/log, and store their PID in a file under /var/run so that other programs can find and signal them. For example, the nginx web server writes its PID to /var/run/nginx.pid.

Viewing Processes

To see the processes running on the system, use ps(1) or top(1). Use ps for a static snapshot and top for a live updating view.

ps

By default, ps only shows processes owned by the current user that are attached to the current terminal:

The output columns are:

• PID — process ID
• TT — the controlling terminal (?? means no terminal, i.e. a daemon)
• STAT — process state (see Process States)
• TIME — cumulative CPU time consumed
• COMMAND — the command that started the process

The most useful set of options is auxww:

• a — show processes of all users
• u — show username and memory usage
• x — include daemon processes with no controlling terminal
• ww — do not truncate long command lines

To show the process tree (parent/child relationships):

To find all processes belonging to a specific user:

To find all processes with a given name, pipe through grep:

The pgrep command is a cleaner way to find PIDs by name:

top

top displays a live-updating view of the most active processes and system resource usage. It refreshes every two seconds by default.

The header section shows:

• The PID of the last process to run and the system load averages (1, 5, and 15 minute averages). A load average near or above the number of CPU cores indicates the system is heavily loaded.
• System uptime and current time.
• A count of running, sleeping, stopped, and zombie processes.
• CPU time breakdown: user, system, idle, interrupt.
• Memory usage: active, inactive, wired, cached, and free.
• If ZFS is active, an ARC line showing how much data was served from the memory cache.
• Swap usage.

Useful interactive commands inside top:

• q — quit
• h — show help
• s — change the refresh interval (prompts for seconds)
• k — kill a process by PID (prompts for PID and signal)
• r — renice a process (prompts for PID and new priority)
• o — change the sort column
• u — filter by username
• m — toggle memory display mode
• p — toggle display of idle processes
• I — toggle display of per-CPU idle time

To run top with a specific refresh interval (e.g. 5 seconds):

To show only processes belonging to a specific user:

Process States

The STAT column in ps output shows the current state of a process. The primary state codes are:

• R — runnable; currently on a CPU or waiting for one
• S — sleeping; waiting for an event such as I/O or a timer, can be interrupted by a signal
• D — disk wait (uninterruptible sleep); typically waiting for I/O to complete. A process stuck in this state usually indicates slow or failing storage.
• T — stopped; suspended by a signal such as SIGSTOP or by the job control mechanism
• Z — zombie; the process has exited but its parent has not yet collected its exit status via wait(2). A zombie consumes no resources other than a PID table entry.
• W — idle (kernel thread)

Additional state modifiers that may follow the primary code:

• s — session leader (typically the login shell)
• + — process is in the foreground process group
• < — process has raised priority
• N — process has reduced priority (niced)
• L — process has pages locked in memory

Signals and Killing Processes

One way to communicate with any running process or daemon is to send a signal using kill(1). Signals are numbered integer values with defined meanings. A user can only send a signal to a process they own. Root can send signals to any process.

To send a signal to a process by PID:

The signal can be specified as a name or number. For example, to send SIGTERM to PID 1234:

Common signals:

• SIGTERM (15) — politely request the process to terminate. The process can catch this signal, flush buffers, close log files, and shut down cleanly. This is the default signal sent by kill when no signal is specified.
• SIGKILL (9) — forcibly terminate the process immediately. This signal cannot be caught or ignored by the process. Use it only after SIGTERM has failed, as it gives the process no chance to clean up.
• SIGHUP (1) — "hang up". Many daemons interpret this as an instruction to reload their configuration file without restarting. For example, sending SIGHUP to named or nginx reloads the configuration.
• SIGINT (2) — interrupt. Equivalent to pressing Ctrl+C in a terminal. Usually causes a process to stop what it is doing and exit.
• SIGQUIT (3) — quit and produce a core dump if the process does not catch it. Equivalent to pressing Ctrl+\.
• SIGSTOP (17) — pause (suspend) the process. Cannot be caught or ignored. The process resumes when it receives SIGCONT.
• SIGCONT (19) — resume a stopped process.
• SIGUSR1 (30) and SIGUSR2 (31) — application-defined signals. Their meaning varies by program; consult the relevant daemon's documentation.
• SIGWINCH (28) — terminal window size changed. Sent automatically when you resize a terminal; programs like top use it to redraw.

To see a full list of signals and their numbers:

To kill a process by name using pkill (sends SIGTERM by default):

To send a specific signal by process name:

To kill all processes matching a name as root:

Never send SIGKILL to init (PID 1). Killing init will halt or reboot the system depending on how the kernel handles it. Likewise, killing core system processes such as devd or the kernel threads visible in ps output can destabilize or crash a running system.

Process Priority

MidnightBSD schedules CPU time among processes using a priority system. Lower priority numbers mean higher priority. The "nice" value is an adjustment to a process's scheduling priority, ranging from -20 (highest priority) to 20 (lowest priority). Regular users can only increase the nice value (lower the priority) of their own processes. Root can set any nice value.

Start a command with a reduced priority (nice value of 10):

Start a command with the maximum reduced priority:

Change the nice value of a running process with renice:

Increase the priority of a process (root only):

Setting long-running background tasks to a higher nice value prevents them from competing with interactive work for CPU time.

Background Jobs and Job Control

The shell's job control feature lets you run multiple commands from a single terminal session by suspending, resuming, and switching between foreground and background jobs.

Append & to a command to run it in the background immediately:

The shell prints the job number and PID, for example [1] 4823. The job continues running while you use the shell for other commands.

To suspend a foreground process and return to the shell prompt, press Ctrl+Z. The process is stopped (SIGSTOP) and the shell reports:

To resume a suspended job in the background:

To bring a background or suspended job back to the foreground:

To list all current jobs in the shell session:

When you close a terminal, the shell normally sends SIGHUP to all its child processes, terminating them. To start a process that survives terminal logout, use nohup:

Output that would have gone to the terminal is redirected to nohup.out in the current directory. Alternatively, use disown after starting a background job to remove it from the shell's job table:

Managing Daemons with service

MidnightBSD uses the rc framework to start, stop, and manage daemons. The service(8) command is the standard interface for interacting with rc scripts without needing to call the scripts directly.

Start a daemon:

Stop a daemon:

Restart a daemon (stop then start):

Reload the daemon's configuration without a full restart (equivalent to SIGHUP for most daemons):

Check whether a daemon is running:

List all available rc services:

List services that are currently enabled in /etc/rc.conf:

Each daemon has a corresponding rc script in /etc/rc.d/ (base system) or /usr/local/etc/rc.d/ (mports). You can call these scripts directly, but using service is preferred as it sets the correct environment.

Starting Daemons at Boot

Whether a daemon starts at boot is controlled by /etc/rc.conf. Most daemons are disabled by default and must be explicitly enabled. The rc script for each daemon defines a variable name following the pattern daemonname_enable.

To enable the SSH server so it starts at boot, add to /etc/rc.conf:

Other common examples:

Many daemons also accept configuration flags through a corresponding daemonname_flags variable:

After editing /etc/rc.conf, start the newly enabled service immediately without rebooting:

To check what rc.conf settings are currently active without opening the file:

The sysrc(8) command also safely adds or removes values without manually editing /etc/rc.conf:

Detailed Process Information

procstat

procstat(1) provides detailed information about a process that goes beyond what ps shows, including open file descriptors, memory mappings, and kernel stack traces.

Show open files for a process:

Show virtual memory mappings:

Show the kernel thread stack (useful for diagnosing hangs):

Show all available information:

fstat

fstat(1) lists open files across all processes or for a specific user. It is useful for finding which process has a file or device open:

sysctl

Several sysctl values expose process and system information:

Show the maximum number of processes allowed on the system:

Show the current number of processes:

Show the load averages: