Ctrlk
VitePress 镜像站QQ 群 787969044视频教程Ⅰ视频教程Ⅱ
discord
For the complete documentation index, see llms.txt. This page is also available as Markdown.

15.4 Processes and Daemons

Overview of Processes and Daemons

FreeBSD is a multitasking operating system. Any program running at any given time is called a process. Each running command starts at least one new process, and there are also many system processes run by FreeBSD.

Each process is uniquely identified by a number called the Process ID (PID). Similar to files, each process has an owner and group, and the owner and group permissions determine which files and devices the process can open. Most processes also have a parent process that started them. For example, a shell is a process, and any command started within the shell is a process with the shell as its parent. The exception is the special process init(8), which is always the first process at system startup and always has PID 1. In FreeBSD, all processes are started under some account.

Port sysutils/htop can visually present this (note the △USER column):

$ htop
  PID△USER       PRI  NI  VIRT   RES S   CPU% MEM%   TIME+  Command
    1 root        20   0 12724  1324 S    0.0  0.0  0:00.08 /sbin/init
  216 root        20   0 36172  7308 S    0.0  0.1  0:00.77 ├─ /usr/local/bin/vmtoolsd -c /usr/local/share/vmware-tools/to
  400 root        48   0 14188  2684 S    0.0  0.0  0:00.00 ├─ dhclient: system.syslog
  403 root         4   0 14188  2760 S    0.0  0.0  0:00.00 ├─ dhclient: em0 [priv]
  481 _dhcp       20   0 14192  2808 S    0.0  0.0  0:00.01 ├─ dhclient: em0
  596 root        20   0 15444  4204 S    0.0  0.1  0:00.05 ├─ /sbin/devd
  800 root        20   0 13904  2792 S    0.0  0.0  0:00.02 ├─ /usr/sbin/syslogd -s
  867 messagebus  20   0 15188  4492 S    0.0  0.1  0:00.29 ├─ /usr/local/bin/dbus-daemon --system
  870 root        20   0 14120  2456 S    0.0  0.0  0:00.06 ├─ /usr/sbin/moused -p /dev/psm0 -t auto
  898 ntpd        20   0 24564  5848 S    0.0  0.1  0:00.06 ├─ /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f
  944 root        68   0 23508  9560 S    0.0  0.1  0:00.00 ├─ sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
  947 root        20   0 13944  2576 S    0.0  0.0  0:00.02 ├─ /usr/sbin/cron -s
  952 root        20   0 56736 23700 S    0.0  0.3  0:00.04 ├─ /usr/local/bin/sddm
  980 root        20   0  257M  124M S    1.0  1.5  0:04.83 │  ├─ /usr/local/libexec/Xorg -nolisten tcp -background none -
  993 root        23   0 50208 27572 S    0.0  0.3  0:00.02 │  └─ /usr/local/libexec/sddm-helper --socket /tmp/sddm-auth-4
  994 ykla        68   0 19992  4620 S    0.0  0.1  0:00.01 │     └─ /usr/local/bin/ck-launch-session /usr/local/bin/start
 1005 ykla        68   0  128M 67736 S    0.0  0.8  0:00.13 │        └─ /usr/local/bin/startplasma-x11
 1010 ykla        68   0  128M 68184 S    0.0  0.8  0:00.25 │           └─ /usr/local/bin/plasma_session
 1017 ykla        20   0  773M  190M S    0.0  2.3  0:01.33 │              ├─ /usr/local/bin/kded6
 1018 ykla        20   0  676M  262M S    0.0  3.2  0:30.96 │              ├─ /usr/local/bin/kwin_x11

Some programs are not designed to continuously receive user input; instead, they disconnect from the terminal after starting. For example, a web server responds to web requests rather than user input, and a mail server is another example of such an application. These types of programs are called daemons. The term "daemon" comes from Greek mythology, representing an entity that is neither good nor evil, silently performing useful tasks. Therefore, BSD's mascot is designed as a cheerful daemon figure wearing sneakers and holding a pitchfork. In Windows systems, such programs are called "services" and can be viewed in the Task Manager.

These long-running background services are typically named xxxd, such as sshd and ntpd, where the d stands for daemon (daemon), which is a common naming convention in UNIX systems. For example, BIND stands for Berkeley Internet Name Domain, but the actual executing program is named named. The Apache web server program is httpd, and the Rsync data synchronization process is rsyncd. However, this is only a naming convention and not a rule; for example, cron and sendmail processes do not end with d.

Viewing Processes

Users can only send signals to processes they own; the root user can send signals to any process. SIGKILL and SIGSTOP signals cannot be caught or ignored. Special PIDs: 0 sends to all processes in the same group, -1 sends to all processes (root) or all of the user's own processes.

To view processes running on the system, you can use ps(1) or top(1). FreeBSD's ps is based on 4.4BSD; BSD-style keywords allow omitting -, such as ps auxww.

To display a static list of currently running processes (including their PID, memory usage, and startup command), use ps(1). To interactively display all running processes and update the display every few seconds to observe system running status, use top(1).

By default, ps(1) only displays processes owned by the current user that have a controlling terminal:

The output of ps(1) consists of multiple columns:

Column
Description

PID

Process ID. PIDs are assigned starting from 1, incrementing to 99999 and then wrapping to the starting value. If a PID is already in use, it will not be reassigned.

TT

The tty on which the program is running.

STAT

The state of the program.

TIME

The amount of time the program has been running on the CPU; this is usually not the elapsed time since the program started, because most programs spend a lot of time waiting for events before needing CPU time.

COMMAND

The command used to start the program.

There are many different options available to change the information displayed. One of the most useful option sets is auxww, where:

Option
Description

a

Display information about processes with controlling terminals for all users. If the system sets security.bsd.see_other_uids=0, non-root users using this option will not be able to view other users' processes.

u

Display the process owner's username and memory usage.

x

Display information about daemon processes.

ps -auxww example:

The ww option enables ps(1) to display the full command line of each process rather than truncating it when it exceeds the screen width. However, because the command line length stored in the kernel is limited, in some cases, the output may still be truncated when using ps with the ww option. For kernel threads, the command field may display a name wrapped in [ ].

The output of top(1) is as follows:

The output is divided into two parts. The header (the first 7 lines in the example command) displays the PID of the last running process, system load averages (a measure of how busy the system is), system uptime (time since the last reboot), and the current time. Other numbers in the header relate to the number of running processes, the amount of memory and swap space used, and the time the system has spent in different CPU states. If the ZFS file system module is loaded, the ARC line indicates how much data was read from the memory cache rather than disk.

Below the header is a series of columns containing information similar to the ps(1) output, such as PID, username, amount of CPU time, and the command that started the process. By default, top(1) also displays the amount of memory space occupied by the process, divided into two columns: one for total size and one for resident size. Total size is the amount of memory the application needs, and resident size is the amount it is actually using. top(1) automatically updates the display every two seconds by default; you can use -s to specify a different interval, such as -s4 to refresh every 4 seconds.

On very busy systems, top may display slightly lagged information because sampling takes time.

Terminating Processes

One way to communicate with any running process or daemon is to send signals using kill(1). There are many different signals; some have specific meanings, while others are described in the application's documentation. Users can only send signals to processes they own; sending signals to other people's processes will result in a permission denied prompt. The exception is the root user, who can send signals to any process.

The operating system can also send signals to processes. If an application is poorly written and attempts to access memory it should not, FreeBSD will send a "segmentation violation" signal (SIGSEGV) to the process. If an application is written to use the alarm(3) system call to receive an alarm after a period of time, it will receive a "alarm clock" signal (SIGALRM).

Two signals can be used to stop a process: SIGTERM and SIGKILL. Because a process can read the signal, close any log files that may be open, and attempt to complete ongoing operations before shutting down, SIGTERM is a gentler way to terminate a process. In some cases, if a process is performing a task that cannot be interrupted, it may ignore SIGTERM.

A process cannot ignore SIGKILL. Sending SIGKILL to a process typically stops it immediately.

Other commonly used signals are SIGHUP, SIGUSR1, and SIGUSR2. Since these are general-purpose signals, different applications will respond differently. For example, after changing a web server's configuration file, you need to tell the web server to re-read its configuration. Restarting httpd would cause a brief downtime for the web server. Instead, you should send a SIGHUP signal to the daemon to make it re-read its configuration. Note that different daemons will have different behaviors, so consult the daemon's documentation to determine whether SIGHUP will achieve the desired result.

Arbitrarily terminating processes in the system is dangerous behavior. Especially init(8), PID 1 is the most special.

Foreground and Background Running of Commands

Ctrl+Z: Suspend (pause) the current process, then use the fg command to bring it back to the foreground:

Appendix: System Monitoring Tool htop

Installation and Configuration

Install using the pkg binary package manager:

Or build and install from source using Ports:

htop Configuration Persistence

htop configuration can be persisted through the interface or configuration file. Note: After saving with F10 in the settings menu, if you exit htop with Ctrl + C, the saved settings will be discarded; you must exit normally with F10 or q to ensure the configuration is written to ~/.config/htop/htoprc.

You can also manually edit the ~/.config/htop/htoprc configuration file in the user directory, adding the following content to enable CPU frequency and temperature display:

References

Exercises

  1. Use ps aux and top to view running system processes, classify them into user processes and system daemons, and analyze the characteristic differences between the two types of processes in terms of parent process relationships and session groups.

  2. Use nice and renice to modify process priorities, record the impact of different nice values on the execution time of CPU-intensive tasks, and analyze how the FreeBSD scheduler handles priorities.

  3. Write a simple daemon script, configure it as an rc.d service, use the service command to start, stop, and query its status, and document the complete lifecycle management process of the service.

Previous15.3 Boot Managers and UEFI FirmwareNext15.5 Managing Services in FreeBSD

Last updated