UNIX System Administration Handbook - Evi Nemeth [492]
portmap/rpcbind: map RPC services to TCP and UDP ports
portmap (which is now called rpcbind on many systems—thanks, Sun!) maps RPC service numbers to the TCP/IP ports on which their servers are listening. When an RPC server starts up, it registers itself with portmap/rpcbind, listing the services it supports and the port at which it can be contacted. Clients query portmap/rpcbind to find out how to get in touch with an appropriate server.
This system allows a port to be mapped to a symbolic service name. It’s basically another level of abstraction above the services file, albeit one that introduces additional complexity (and security issues) without solving any real-world problems. Many RPC programs are actually started by way of inetd, thus providing not one but two full layers of indirection and deceit.
If portmap/rpcbind dies, all the services that rely on it (including inetd and NFS) must be restarted. In practical terms, this means that it’s time to reboot the system. portmap/rpcbind must be started before inetd in order for inetd to handle RPC services correctly.
28.4 SYSTEM DAEMONS
A few system tasks, such as managing virtual memory and synchronizing the disk cache, are managed by daemons rather than by the kernel itself. The daemons that perform these functions cannot be manipulated by the system administrator and should generally be left alone.
The paging daemon
The implementation of this daemon and its exact function vary widely across systems. It is named pageout on Solaris, vhand on HP-UX, kpiod under Red Hat, and pagedaemon under FreeBSD.
This daemon is part of the virtual memory system. When a page of virtual memory is accessed, the system’s hardware consults a table to determine whether the page is currently in physical memory. If not, a fault occurs and the paging daemon is called to bring the page into memory from the swap area. If no physical pages are available, the paging daemon makes room by writing out some other page to the swap device and updating the appropriate page table entries.
See page 760 for more information about virtual memory.
The swapping daemon
This daemon is called swapper on FreeBSD and HP-UX, and kswapd on Linux.
When many processes are running simultaneously, the system begins to spend a lot of time processing page faults because each process has a certain number of pages that it accesses regularly. This condition is called thrashing, and it can seriously degrade performance.
The swapping daemon monitors the number of page faults that occur in proportion to the number of memory references. If too many faults occur, the swapping daemon starts to move entire processes out to the swap space. Swapped processes are completely removed from physical memory and are prevented from running for a comparatively long time (seconds). The swapping daemon continues to eliminate processes until the page fault rate falls to an acceptable level.
Swapping was designed for an era in which physical memory was very expensive, and the need for it in today’s computing landscape is questionable. Nevertheless, most systems still provide this capability.
The filesystem synchronization daemon
The filesystem synchronization daemon executes the sync system call every 30 seconds. sync causes all “dirty” disk blocks to be written out, including filesystem superblocks, inode tables, and buffered data blocks.4 This housekeeping minimizes the filesystem damage that can occur during a crash.
See page 133 for more information about filesystem superblocks.
On most systems this daemon is called update, but HP-UX calls it syncer and Solaris calls it fsflush.
28.5 PRINTING DAEMONS
The BSD and System V printing systems each have their own family of daemons that provide printing-related services. In some cases the families have been hybridized, and in others both variants run on a single system.
lpd: manage BSD-style printing
lpd is responsible for the BSD print spooling system. It accepts jobs from users and forks processes that perform the actual