Should all daemons be there when you check for them? Actually, no. Back in the days when memory was scarce, the concept of a receptionist daemon was invented so that daemons not in use weren’t loaded into memory. This receptionist is called inetd (Internet daemon) and is responsible for listening for connections, telling the caller to hold on, and then waking up the right daemon and transferring the call. Daemons that are invoked this way include telnetd (Telnet daemon) and ftpd (FTP daemon), among others. You can see which daemons are invoked by inetd by looking at the contents of inetd.conf, which will look something like this:

# If you make changes to this file, either reboot your machine or send
# the inetd a HUP signal:
# Do a “ps x” as root and look up the pid of inetd. Then do a
# “kill -HUP <pid of inetd>”.
# The inetd will re-read this file whenever it gets that signal.
# Echo, discard, daytime, and chargen are used primarily for testing.
# Format is:
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
echo    stream  tcp   nowait  root   internal
echo    dgram   udp   wait    root   internal
discard stream  tcp   nowait  root   internal
discard dgram   udp   wait    root   internal
daytime stream  tcp   nowait  root   internal
daytime dgram   udp   wait    root   internal
chargen stream  tcp   nowait  root   internal
chargen dgram   udp   wait    root   internal
ftp     stream  tcp   nowait  root   /usr/sbin/tcpd  /usr/sbin/wu.ftpd -a
telnet  stream  tcp   nowait  root   /usr/sbin/tcpd  /usr/sbin/in.telnetd

You can start and stop inetd by using the kill commands outlined earlier. This tends to be a bigger deal than just killing one daemon, because inetd acts as a receptionist for many services; it’s best to use kill -HUP PID to make inetd reread its configuration first.

However, certain really important daemons do run on their own, namely the DNS naming daemon (named), also sometimes known as in.named. You can stop and restart these in the same way as with httpd, earlier, without worrying about what other services might be affected.

In particular to named, if it’s running but doesn’t give out the right information even after a restart, you might want to check to make certain the named configuration files are okay (you can always restore from a “known good” backup). The primary named file lives under /etc/named.boot, and it refers to several other files that are integral to its operation. See the man page for more information than you ever wanted to know about named.

---

It’s worth mentioning that the client for named on a UNIX server does not always perform name lookups from its own name server; not every UNIX server runs a name server. Take a look at the /etc/resolv.conf file to see how you’re configured.

---

Not every service runs on a single daemon. NFS (Network File System, the file and print service for UNIX), for example, does not. It runs different daemons for different tasks—biod, nfsd, mountd—and relies on another daemon called portmapper. NFS can be a beast; if you’re lucky enough to use a system that has per-service startup scripts, you might be able to restart NFS by typing the following:

# cd /etc/init.d
# ./S80nfs stop
# ./S80nfs start

Usually, systems that use SVR4 (pronounced Ess Vee Are Four, short for System V, Release 4) standards, such as UNIXWare or Red Hat Linux, will have these types of startup and stop scripts. If your system is based more on the University of Berkeley revision of UNIX (BSD, or Berkley Standard Distribution), as is the case with AIX or Slackware Linux, everything will have a start command somewhere in a file called /etc/rc.something, but you won’t have fine control over starts and stops.

You can check out who’s allowed to use a given file system (the equivalent of a share under Windows NT) by looking at the /etc/exports file. If you add or change access in this file, you’ll need to run the exportfs -a command. The host name you add should be listed in the /etc/hosts file or in your DNS zone (for example, company.com).