david hunt <dh(_at_)west(_dot_)net> writes:
On Tue, 16 Dec 1997, Philip Guenther wrote:
What are the permissions on /usr/mail, and is procmail setuid or setgid
anything?
/usr/mail seems to be a symbolic link to /var/mail. /var/mail has 't', but
I don't know what that means.
$ ls -al /usr/mail
lrwxrwxrwx 1 root root 11 May 26 1995 /usr/mail -> ../var/mail
$ ls -al /var (trimmed to 'mail' listing)
drwxrwxr-t 4 root mail 107008 Dec 16 13:17 mail
Hmm, it's not world writable. Is procmail setuid root? If not, then
you're either going to have to live with those messages, or place the
following at the end of your .procmailrc:
:0
$DEFAULT
:0e
$ORGMAIL
That'll have procmail do the deliveries sans dotlocking. Since you
have kernel locking of some sort (if my memory is right), that'll be
fine, assuming that your mail reader uses the same kernel locking as
procmail. Check the output of "procmail -v" and the manpage for your
mailreader to be sure.
Hmm, alternatively, you could try to talk your sysadmin into making
procmail setgid mail. That would let it do the dotlocking. Installing
it in /usr/bin or /usr/local/bin would probably be integral with that
action, if it actually occured.
...
I'll bet that would fix it. I just need to know what I'm talking about to
have a meaningful discussion with the sysadmin. He has to realize it's in
his best interest, since he's got his hands full with other stuff.
If you think a testemonial would help, have him e-mail me.
Is this the sort of track kernal-locking leaves? And is kernal-locking
bad? Does NFS mounted devices have anything to do with this? I've seen
temporary files appear in ~/ with "nfs" in the filename when I don't
specify LOGFILE.
Unless it fails, kernel locking is silent (even with VERBOSE=on). If
you're not sure if it's there, check the output of "procmail -v". Is
kernel locking bad? If it works, it's good. If it doesn't, it's bad.
The problem with NFS mounts is kernel locking over NFS is hard to do
correctly, such that most implementations have had serious bugs of
various sorts that reduce one's willingness to trust them with anything
at all. Last I checked, there were still outstanding bugs reported in
Solaris 2.5. Maybe they've got them fixed in 2.6, but it says
something that Sun, the company which developed NFS to start with, has
had a very hard time with it.
As for those temporary file, they're probably named ".nfs######" or
something like that (the ###### is some gooblygook related to the NFS
filehandle) Those are from a file is deleted from a NFS client where
the file is still being help open. UNIX file semantics demand that the
filename vanish, but that the file remain accessible until it's
closed. It's unlikely that they have anything to do with LOGFILE being
set or unset.
Philip Guenther