UNIX System Administration Handbook - Evi Nemeth [490]
On FreeBSD systems, you can tell init to reread its control file by sending it a hangup signal (SIGHUP). Since init’s PID is always 1, you can simply run kill -HUP 1. Don’t forget the -HUP, or you will bring your system to a grinding halt.
28.2 CRON: SCHEDULE COMMANDS
The cron daemon is responsible for running commands at preset times. It accepts schedule files (“crontabs”) from both users and administrators.
cron is frequently employed for administrative purposes, including management of accounting and log files and daily cleanup of the filesystem. In fact, cron is so important to system administrators that we have devoted an entire chapter to it. That chapter, Periodic Processes, begins on page 157.
28.3 INETD: MANAGE DAEMONS
inetd is a daemon that manages other daemons. It starts up its client daemons when there is work for them to do and allows them to die gracefully once their tasks have been completed.
inetd only works with daemons that provide services over the network. To find out when someone is trying to access one of its clients, inetd attaches itself to the network ports that would normally be managed by the quiescent daemons. When a connection occurs, inetd starts up the appropriate daemon and connects its standard I/O channels to the network port. Daemons must be written with this convention in mind to be compatible with inetd.
Some daemons (such as those associated with NIS and NFS) rely on a further layer of indirection known as the Remote Procedure Call (RPC) system. RPC was originally designed and implemented by Sun as a way of promoting the sharing of information in a heterogeneous networked environment. Port assignments for daemons that use RPC are managed by the portmap daemon (also known as rpcbind on some systems), which is discussed later in this chapter.
Many daemons can be used in either the traditional way (in which they are started once and continue to run until the system shuts down) or with inetd. Daemons discussed in this chapter are marked with an if they are inetd-compatible.
Configuring inetd
inetd consults a config file (usually /etc/inetd.conf) to determine which network ports it should listen to. The format is the same on all platforms. Here’s a sample:
ftp stream tcp nowait root /usr/sbin/ftpd ftpd
telnet stream tcp nowait root /usr/sbin/telnetd telnetd
shell stream tcp nowait root /usr/sbin/rshd rshd
finger stream tcp nowait guest /usr/sbin/fingerd fingerd
bootp dgram udp wait root /usr/sbin/bootpd bootp -f
pop-2 stream tcp nowait root /usr/sbin/popper popper
pop-3 stream tcp nowait root /usr/sbin/popper popper
mountd/1 stream rpc/tcp wait root /usr/sbin/mountd mountd
mountd/1 dgram rpc/udp wait root /usr/sbin/mountd mountd
...
The first column contains the service name. inetd maps service names to port numbers by consulting either the /etc/services file (for TCP and UDP services) or the portmap daemon (for RPC services). RPC services are identified by names of the form name/num and the designation rpc in column three. In the example above, the last two lines are RPC services.
The second column determines the type of socket that the service will use and is commonly stream or dgram. In general, stream is used with TCP (connection-oriented) services, and dgram is used with UDP.
The third column identifies the communication protocol used by the service. The allowable types are listed in the protocols file (usually in /etc). The protocol is almost always tcp or udp. RPC services prepend rpc/ to the protocol type, as with rpc/tcp and rpc/udp in the example above.
If the service being described can process multiple requests at one time (rather than processing one request and exiting), column four should be set to wait; this option prevents inetd from constantly