> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/ask/flat/chapter-15-system-booting/di-15.4-jie-jin-cheng-yu-shou-hu-jin-cheng.md). # 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): ```sh $ 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](https://www.freebsd.org/copyright/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: ```sh $ ps PID TT STAT TIME COMMAND 1971 0 Is 0:00.03 -sh (sh) 2183 1 Ss 0:00.05 -sh (sh) 2186 1 R+ 0:00.00 ps ``` 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: ```sh $ ps -auxww USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 1592.5 0.0 0 256 - RNL 11:51 648:25.89 [idle] root 0 0.0 0.1 0 4240 - DLs 11:51 0:05.08 [kernel] ...partial output omitted... _dhcp 792 0.0 0.1 14656 3532 - ICs 11:51 0:00.04 dhclient: em0 (dhclient) root 1211 0.0 0.1 14652 3156 - Is 11:51 0:00.00 /usr/sbin/moused -p /dev/input/event5 -t evdev -I /var/run/moused.event5.pid ...partial output omitted... root 1974 0.0 0.1 14816 3532 0 I 12:04 0:00.01 su root 1975 0.0 0.1 14872 3728 0 I+ 12:04 0:00.03 su (sh) ykla 2183 0.0 0.1 14872 3728 1 Ss 12:28 0:00.05 -sh (sh) ykla 2191 0.0 0.1 14956 3576 1 R+ 12:31 0:00.00 ps -auxww ``` 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: ```sh $ top last pid: 2189; load averages: 0.24, 0.13, 0.04 up 0+00:39:10 12:30:35 30 processes: 1 running, 29 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 26M Active, 21M Inact, 260M Wired, 2056K Buf, 3617M Free ARC: 35M Total, 6321K MFU, 27M MRU, 128K Anon, 407K Header, 1467K Other 19M Compressed, 52M Uncompressed, 2.76:1 Ratio Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 2183 ykla 1 0 0 15M 3728K wait 9 0:00 0.10% sh 1623 ntpd 2 0 0 26M 7072K select 12 0:00 0.00% ntpd 1783 root 1 0 0 15M 3708K ttyin 5 0:00 0.00% sh 2179 root 1 3 0 25M 12M select 12 0:00 0.00% sshd-session 1714 root 1 0 0 25M 11M select 5 0:00 0.00% sshd 1756 root 1 1 0 14M 3076K nanslp 14 0:00 0.00% cron 1496 root 1 0 0 14M 3456K kqread 15 0:00 0.00% syslogd 1224 root 1 0 0 16M 4668K select 0 0:00 0.00% devd 1967 root 1 1 0 25M 12M select 11 0:00 0.00% sshd-session 792 _dhcp 1 0 0 14M 3532K select 1 0:00 0.00% dhclient 2182 ykla 1 0 0 25M 12M select 4 0:00 0.00% sshd-session 1970 ykla 1 0 0 25M 12M select 5 0:00 0.00% sshd-session 1975 root 1 1 0 15M 3728K ttyin 1 0:00 0.00% sh 1971 ykla 1 9 0 15M 3720K wait 9 0:00 0.00% sh 1499 root 1 0 0 14M 3276K select 15 0:00 0.00% syslogd 1638 root 1 0 0 14M 3160K kqread 8 0:00 0.00% moused 1974 ykla 1 7 0 14M 3532K wait 15 0:00 0.00% su ``` 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: ```sh # ping 163.com # Test network connectivity to 163.com PING 163.com (59.111.160.244): 56 data bytes 64 bytes from 59.111.160.244: icmp_seq=0 ttl=52 time=27.611 ms 64 bytes from 59.111.160.244: icmp_seq=1 ttl=52 time=27.691 ms ^Z[1] + Suspended ping 163.com # Note here, Ctrl+Z was pressed # fg # Return to foreground ping 163.com 64 bytes from 59.111.160.244: icmp_seq=3 ttl=52 time=27.465 ms 64 bytes from 59.111.160.244: icmp_seq=4 ttl=52 time=27.586 ms 64 bytes from 59.111.160.244: icmp_seq=5 ttl=52 time=27.522 ms ^C # Press Ctrl+C to end the command --- 163.com ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 27.465/27.596/27.701/0.085 ms ``` ## Appendix: System Monitoring Tool htop ### Installation and Configuration **Install using the pkg binary package manager:** ```sh # pkg install htop ``` **Or build and install from source using Ports:** ```sh # cd /usr/ports/sysutils/htop/ # make install clean ``` ### 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: ```ini show_cpu_frequency=1 # Enable current CPU frequency display show_cpu_temperature=1 # Enable CPU temperature display ``` ### References * htop-dev. Settings are not saved\[EB/OL]. \[2026-03-25]. . Discussion on common issues and solutions for htop configuration saving. ## 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.bsdcn.org/ask/flat/chapter-15-system-booting/di-15.4-jie-jin-cheng-yu-shou-hu-jin-cheng.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.