Creation Date: July 12, 1998
Keywords: Mail, sendmail
Disclaimer
This document pertains to the NeXTSTEP operating system, which is no longer a supported product of Apple Computer. This information is provided only as a convenience to our customers who have not yet upgraded their systems, and may not apply to OPENSTEP, WebObjects, or any other product of Apple Enterprise Software. Some questions in this Q&A document may not apply to version 3.3 or to any other specific version of NeXTSTEP.
Sendmail Questions
Q: Why is sendmail timing out to my local mailhost?
Q: Why do I get "connection timed out" messages while trying to connect to my local mailhost. When I log in to the mailhost, it seems lightly loaded?
Q: Why is mail taking so long to deliver locally?
A: There are probably several possible answers to these questions. Here is one of them.
Mail gets queued up in /usr/spool/mqueue using two different files for each piece of mail. One file is the header information for the mail, and the other file is the body of the message. The directory /usr/spool/mqueue, like all directories, is simply a file that contains a listing of filenames and their associated inodes that are contained in the directory. The size of a directory is usually around 1 or 2 kilobytes. The more files you have in a directory and the longer the names of the files, the larger the size of the directory file is. The size of the directory file never decreases.
Whenever a file is created the system must open up the directory file and write some information into it. The larger the directory file is, the longer it takes to read through it and add the new entry. The same thing is true for deleting files.
If you have a mail server that deals with a lot of traffic and something causes the mail to get backed up in the queue, the directory file can grow very large (50+ KB) storing the names of the backed up mail. Even after clearing the entire queue, the size of the directory file remains the same, and creating and destroying files in that directory starts taking a significant amount of time. In fact, the mail server can become so slow that connections to it start timing out even though the machine seems to be very responsive.
The only solution is to create a new mqueue directory:
1. Find the incoming sendmail process and kill it.
% ps auxw | grep sendmail
root 206 0.0 0.8 1.55M 312K ? S 0:04 -accepting connections (sendmail)
% kill <PID># PID is 206 in the above example
2. Wait for the outgoing sendmail processes to finish.
% ps auxw | grep sendmail
You can keep running the above command until all of the outgoing sendmail processes have died or you can go ahead and kill them all. Sendmail should be tolerant of getting killed.
3. Move /usr/spool/mqueue to /usr/spool/mqueue.old and create a new mqueue
% cd /usr/spool
% mv mqueue mqueue.old
% mkdir mqueue
5. Move all of the files from mqueue.old into the new mqueue directory
% mv mqueue.old/* mqueue
6. Remove old mqueue directory
% rmdir mqueue.old
6. Restart sendmail
% /usr/lib/sendmail -bd -q30m
Valid for 1.0, 2.0, 3.0
Q: How do I cause mail to be automatically forwarded to destinations outside our local network through some outside service?
A: You'll need to make some minor changes to your mailhost's sendmail.cf file. The sendmail configuration file, /etc/sendmail/sendmail.cf is either a link to sendmail.mailhost.cf or is some variant of the mailhost configuration. You edit this file on your mailhost--the machine which is responsible for forwarding mail.
Look for the following lines near the top of the file (in the default sendmail.mailhost.cf, they start at line 30):
# If you want to use a relay mailer, examine ruleset 0. There are some
# rules that need to be uncommented
DMuucp
# major relay host: use the $M mailer to send mail to other domains
# To have mail automatically forwarded to other domains, you should
# replace this with the name of your major relay host.
DR mail-relay
CR mail-relay
The line
DMuucp
tells sendmail that mail destined for a machine off the local network should be forwarded using the ``uucp'' mailer -- i.e., using the UNIX UUCP facility. The lines
DR mail-relay
CR mail-relay
indicate that the machine called mail-relay is the forwarding host. Change these three lines to reflect your actual situation. Typically, uucp is the appropriate mailer if you're not on the Internet. Either replace mail-relay with the name of your UUCP partner, or ensure that mail-relay is a host alias of that partner. (Note that if you make mail-relay be an alias for that partner and you're using UUCP as the relay mail mechanism, you have to modify the UUCP configuration files to reflect this alias.)
If you look at the comments which begin the excerpt included above, you see a note regarding uncommenting some lines in ``ruleset 0.'' Look for the following lines in sendmail.cf (at line 323 in the default sendmail.mailhost.cf):
# If you want to pass all other explicit domain names up the ladder
# to our forwarder then uncomment the following line.
#R$*<@$*.$+>$* $#$M $@$R $:$1<@$2.$3>$4 user@any.domain
# and comment out this one.
R$*<@$+.$->$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4 user@any.domain
These lines describe how to forward non-local mail. In the default file for a mailhost, such mail is forwarded using the ddn mailer (i.e., over the Internet). We want to change that, to use the mail specified above, in the DM line. To do this, uncomment the third line and comment out the fifth line:
# If you want to pass all other explicit domain names up the ladder
# to our forwarder then uncomment the following line.
R$*<@$*.$+>$* $#$M $@$R $:$1<@$2.$3>$4 user@any.domain
# and comment out this one.
#R$*<@$+.$->$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4 user@any.domain
WARNING: Be very careful when you modify a sendmail configuration file. As you might notice, the syntax is arcane and cryptic, and the ``rewriting rules'' in the configuration file are intricate.
Valid for 1.0, 2.0 ,3.0, 3.1
Q: My Release 3.0 client or mailhost machines are extremely slow. When I look at the processes, I see that there are several hung sendmail processes, and mail isn't being sent. My mailhost is a Sun (or a third party PC gateway program such as Banyan Vines or CCMAIL).
A: There are timing problems within the sendmail code on Release 3.0 that cause
mail traversing Sun mailhosts (and certain mail gateways such as Banyan
Vines and CCMAIL) to hang and take up excessive process time. The symptoms usually are:
* Machine is extremely slow.
* The sendmail process is using too much CPU time, or many sendmail processes are running, but never complete.
* Mail is not being delivered to the mailhost, or to the gateway.
The solution is as follows:
* Rename the file /usr/lib/sendmail to /usr/lib/sendmail.30.
* Copy /usr/lib/sendmail.old to /usr/lib/sendmail. The file sendmail.old is NeXT's Release 2 version of sendmail, and alleviates the timing errors.
Perform this procedure on Release 3.0 clients and/or any NeXT mailhosts which are forwarding mail to one of the above gateways.
Make sure the permissions are set correctly on the sendmail file:
Q: When I have a Sun Solaris 2.4 system as an NFS client and a NEXTSTEP 3.3 system as the NFS server, the access starts out very slow. What casues this and is there a way to speed up the access time?
A: This problem is caused by a change in the Solaris NFS code in the 2.4 release. The new version of NFS READDIR in the Solaris 2.4 release trys to request more than 1024 bytes of directory data (this gains faster reponse from the NFS servers that support the larger size). The NEXTSTEP NFS server (and other NFS servers which are based on older NFS source code) fail to repond to this request. Sun Solaris will retransmit the READDIR requests and eventually will dynamically change the rsize and wsize values for the mount to smaller values. You may verify this on the Sun with nfsstat -m command. In about 2 to 5 minutes the rsize and wsize will be reduced and the READDIR requests to the Next start working!
To workaround this problem set the rsize and wsize for the mount entries on a Solaris 2.4 NFS client to 1024 for all mounts from NEXTSTEP NFS servers.
Q: I logged in on an NFS client, and the Workspace Manager indicated that my home directory (which it knows correctly) is not a directory, and it can't change to the directory. Yet, there are no errors during (verbose) boot with the mount. My home directory is on a server. Everything looks correct in NetInfo. What's going on?
A: Check the current date on the client. Apparently, if it's extremely screwed up (e.g., something before the epoch, Thu Jan 1 00:00:00 1970), the NFS accesses don't function correctly.
Q: Why is the performance of my file server so poor? The load is high and rpc.mountd is taking up large chunks of CPU time.
A: There is a file called /etc/rmtab, which contains statistics about remotes mounts. See the man page rmtab(5) for details. When an NFS client crashes, it does not remove its entry in this file and so as more NFS clients crash, the file /etc/rmtab on the file server grows without bound. Eventually things break or slow down severely. Notable symptoms are:
* The file /etc/rmtab is large--there should only be one line for each NFS client mounting a file system.
* High %CPU (e.g., higher than any other process) value as shown by ps -aux:
nfsserver% ps -aux | grep mount
USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND
root 276 19.6 1.4 1.23M 224K ? S 0:00 rpc.mountd ...
* High load values on the server immediately following multiuser boot.
* Home directories not mounting properly.
The fix is as follows:
1) Boot the machine in single-user mode.
2) Empty the file /etc/rmtab (e.g., cat /dev/null > /etc/rmtab).
3) Reboot.
This solves the problem.
Q: I've exported a directory from a file server. Some machines (perhaps) can mount that directory successfully, others cannot, and receive a message like:
Access denied for server:/directory
The directory on the server is exported for universal access (e.g., nidump exports . reports something like
/directory -ro
granting any machine read-only access rights). What's going on?
A: What's likely wrong here is that the server doesn't know about the client. Check the appropriate hosts databases (the machines directory in NetInfo, for example) in all applicable domains. The client must appear in there somewhere.
This typically will not be seen in a two-level NetInfo hierarchy, but could be seen in a three-level hierarchy.
This feature is an important part of NFS security, and is not a bug.
NIS/YP Questions
Q: My NIS (Yellow Pages) database doesn't seem to be examined correctly. One symptom, for instance, is that ypbind is running fine and ypcat works great, but ~user doesn't work.
A: This is likely caused by the lack of a + line in the UNIX flat file. If something isn't found in NetInfo, the system looks in the appropriate UNIX flat file. If that file is to "include" the appropriate NIS map, it must have a proper + line in it. At the point where NIS might be examined, it's as if the NetInfo database did not exist, and was not referenced.
![[Index]](http://enterprise.apple.com/NeXTanswers/images/index.gif)
![[Download]](http://enterprise.apple.com/NeXTanswers/images/Download.gif)
