bellmail error - why?

bellmail error - why?

Post by Geral » Mon, 12 Jul 1999 04:00:00



In the /var/spool/mqueue directory I am getting files with names like
xfPAA16888 (along with the normal qfPAA16888 and dfPAA16888). When I
get the "xf" files, mail is not delivered. The contents of the "xf"
files are similar to:

bellmail: error closing file: Permission denied
/usr/spool/mail/spaceadm.lock: Permission denied
/usr/spool/mail/spaceadm.lock: Bad file number
/usr/spool/mail/spaceadm.lock: Bad file number
.
. (keeps repeating the same line over and over)
.
/usr/spool/mail/spaceadm.lock: Bad file number

In /tmp, there exists a temporary file that always starts with ma
(e.g., mabq6Ma) that contains the message that you would expect in
/var/spool/mail. That is, it looks like:

From joe Sun Jul 11 15:41:02 1999

receivehostname.domainname (AIX4.2/UCB
8.7/8.7) with SMTP id PAA16888 for <spaceadm>; Sun, 11 Jul 1999
15:40:42 -1000 (HST)
Date: Sun, 11 Jul 1999 15:40:42 -1000 (HST)
From: "Sender's Name" <joe>

To: spaceadm
Subject: test

test    

What would cause the "xf" file with the bellmail error?

Note: /usr/spool/mail is NFS mounted. /etc/exports on the NFS server
has the root option set (e.g., /usr/spool/mail
-root=hosta:hostb:hostc). If I unmount /usr/spool/mail, the problem
goes away but I would really like to understand what the root cause
is. I would like to keep the mail directory NFS mounted so that users
can access their mail (common directory) from any host (e.g., hosta,
hostb or hostc from the example /etc/exports above).

 
 
 

bellmail error - why?

Post by NICHOLAS DRON » Tue, 13 Jul 1999 04:00:00


: In the /var/spool/mqueue directory I am getting files with names like
: xfPAA16888 (along with the normal qfPAA16888 and dfPAA16888). When I
: get the "xf" files, mail is not delivered. The contents of the "xf"
: files are similar to:

: bellmail: error closing file: Permission denied
: /usr/spool/mail/spaceadm.lock: Permission denied
: /usr/spool/mail/spaceadm.lock: Bad file number
: /usr/spool/mail/spaceadm.lock: Bad file number
: .
: . (keeps repeating the same line over and over)
: .
: /usr/spool/mail/spaceadm.lock: Bad file number

: In /tmp, there exists a temporary file that always starts with ma
: (e.g., mabq6Ma) that contains the message that you would expect in
: /var/spool/mail. That is, it looks like:

: From joe Sun Jul 11 15:41:02 1999

: receivehostname.domainname (AIX4.2/UCB
: 8.7/8.7) with SMTP id PAA16888 for <spaceadm>; Sun, 11 Jul 1999
: 15:40:42 -1000 (HST)
: Date: Sun, 11 Jul 1999 15:40:42 -1000 (HST)
: From: "Sender's Name" <joe>

: To: spaceadm
: Subject: test

: test    

: What would cause the "xf" file with the bellmail error?

: Note: /usr/spool/mail is NFS mounted. /etc/exports on the NFS server
: has the root option set (e.g., /usr/spool/mail
: -root=hosta:hostb:hostc). If I unmount /usr/spool/mail, the problem
: goes away but I would really like to understand what the root cause
: is. I would like to keep the mail directory NFS mounted so that users
: can access their mail (common directory) from any host (e.g., hosta,
: hostb or hostc from the example /etc/exports above).

The xf* file is the transcript of the session associated with that
message ID.  The "Bad file number" error indicates that the bellmail
process is trying to unlock and close a file which has been removed.
I don't know whether the 'Permission denied' error is because bellmail
is running as root and root doesn't have permission to write to the
mount, or because the file has been removed.  (Both of these don't
quite fit: I do see that you have exported the directory with the
root option for this host; I don't see how a 'Permission denied'
error would come from trying to close a file that has been removed
unless it were locked by another process, but even there 1) your
client doesn't know the inode of the file (see below) and 2) I
suspect -- perhaps wrongly -- that bellmail does respect advisory
file locking, which -- if correct -- would likely mean that
it would sleep waiting for the lock to be freed.)

More precisely, the inode number of the file has changed even
though the name is the same.  The RPC packets that the client's
biod sends to the server contain a filehandle which consists
of -- if my memory serves me right -- the major and minor numbers
of the block device on the server on which the file resides and
the file's inode number.  The nfsd on the server receieves the
request, interprets it and passes it on to the kernel.  The kernel
returns the "Bad file number" error to its nfsd when it finds that
the inode is neither in its inode cache or on disk, and the nfsd
returns the error to the client biod via RPC.

But this doesn't solve your problem.

Does the entry for /usr/spool/mail in /etc/exports appear exactly
as you described?  Are those all of the options listed?  Also (and
I'm not questioning your abilities here) can you confirm that the
root option is actually in effect?  Can root on the client create
a file in /usr/spool/mail?

I've never spent time debugging NFS file locking (which is done by
rpc.lockd and rpc.statd, which should be running on the client).
The least I can say is that you should make sure that you've got the
latest NFS, networking and kernel code for AIX 4.2.x (whatever you
happen to be running, it better be 4.2.1. :)  In other words, there
may be a locking problem with NFS at AIX 4.2.1, but I have no idea
whether that's *really* the direction you should take to get your
mail system working as desired.

You may want to get _Managing NFS and NIS_, by Hal Stern, who works
or used to work for Sun and is clearly an expert on these matters.

The book contains a section on centralizing mail services with NFS
and (gasp) NIS (but NIS is not required to get it working as he
suggests).  It appears that the recommended way of doing this is
to export the mail spool to the client for reading purposes only
(the mount should be rw,hard, which are the defaults with AIX 4.2
unless you specify otherwise), and have all mail forwarded to the
mail hub.  That is, no mail will be delivered locally.

This is what I got out of a glance at that section of the book, so
don't take my word for it.  Also, someone more knowledgable in
these matters than I may have more and better things to say about it.

Whatever the case,

Best wishes,

Nicholas

 
 
 

bellmail error - why?

Post by Leonard Sali » Sat, 17 Jul 1999 04:00:00


: : In the /var/spool/mqueue directory I am getting files with names like
: : xfPAA16888 (along with the normal qfPAA16888 and dfPAA16888). When I
: : get the "xf" files, mail is not delivered. The contents of the "xf"
: : files are similar to:

: : bellmail: error closing file: Permission denied
: : /usr/spool/mail/spaceadm.lock: Permission denied
: : /usr/spool/mail/spaceadm.lock: Bad file number
: : /usr/spool/mail/spaceadm.lock: Bad file number
: : .
: : . (keeps repeating the same line over and over)
: : .
: : /usr/spool/mail/spaceadm.lock: Bad file number

: : In /tmp, there exists a temporary file that always starts with ma
: : (e.g., mabq6Ma) that contains the message that you would expect in
: : /var/spool/mail. That is, it looks like:

: : From joe Sun Jul 11 15:41:02 1999

: : receivehostname.domainname (AIX4.2/UCB
: : 8.7/8.7) with SMTP id PAA16888 for <spaceadm>; Sun, 11 Jul 1999
: : 15:40:42 -1000 (HST)
: : Date: Sun, 11 Jul 1999 15:40:42 -1000 (HST)
: : From: "Sender's Name" <joe>

: : To: spaceadm
: : Subject: test

: : test    

: : What would cause the "xf" file with the bellmail error?

: : Note: /usr/spool/mail is NFS mounted. /etc/exports on the NFS server
: : has the root option set (e.g., /usr/spool/mail
: : -root=hosta:hostb:hostc). If I unmount /usr/spool/mail, the problem
: : goes away but I would really like to understand what the root cause
: : is. I would like to keep the mail directory NFS mounted so that users
: : can access their mail (common directory) from any host (e.g., hosta,
: : hostb or hostc from the example /etc/exports above).

<stuff deleted>

: You may want to get _Managing NFS and NIS_, by Hal Stern, who works
: or used to work for Sun and is clearly an expert on these matters.

: The book contains a section on centralizing mail services with NFS
: and (gasp) NIS (but NIS is not required to get it working as he
: suggests).  It appears that the recommended way of doing this is
: to export the mail spool to the client for reading purposes only
: (the mount should be rw,hard, which are the defaults with AIX 4.2
: unless you specify otherwise), and have all mail forwarded to the
: mail hub.  That is, no mail will be delivered locally.

: This is what I got out of a glance at that section of the book, so
: don't take my word for it.  Also, someone more knowledgable in
: these matters than I may have more and better things to say about it.

: Whatever the case,

: Best wishes,

: Nicholas

Sendmail's bad behavior when it tries to lock files in an NFS-mounted
spool directory seems, from my experience, to be a "feature" that was
introduced in the sendmail v8.7 that was delivered with AIX 4.2 and
continued in sendmail v8.8 in AIX 4.3.  The sendmail v5.6 in AIX 3.2.5
ans AIX 4.1 doesn't exhibit this behavior.  I "re-looked at" the O'Reilly
"bat" sendmail book and the "porcupine" NFS/NIS book after reading your
post.  I'd been struggling with the same problem situation for a while,
but I had been assuming it was an NFS incompatibility problem between my
AIX 4.1.5 mail spool NFS server and my new AIX 4.3.2 clients.  Your post
got me on the right track, thank you.

The "bat" book seems to hint that a file locking problem is likely to
occur, but it doesn't say why in terms that I understand.  It's
references to the flock(2) and fcntl(2) system calls don't strike a note
of recognition in my brain.  Can someone with more experience post a
more definitive explanation of what's going wrong when the spool
directory is NFS-mounted?

The suggestions on how to implement the mail hub in Stern's "porpcupine"
book seem to be based on a sendmail.cf from an earlier version of
sendmail than I.B.M. delivers with AIX 4.2 and 4.3.  The second edition
of the "bat" book matches versions nicely with AIX 4.3.2.  I understood
it to suggest the use of the "H" macro to define a mail hub (i.e.
"DHnfs_server").  My mail configuration has no "MX" records and no entries
in /etc/aliases, and I have reasonable assurance that all login-ids on
the NFS clients are known on the NFS server for the spool directory.  I
was already using "DS" to get mail sent off-local-network.  I left "DR"
null (the default) and added "DHnfs_server".  Is this sufficient to get
all mail forwarded to the NFS spool server, or have I shot myself in
some other foot?  Some of my concern comes from the fact that although
I can see the "H" macro being used in sendmail.cf, there isn't a
nulled or commented out line inviting its use like there is for "R" and
"S".

 
 
 

bellmail error - why?

Post by Geral » Sat, 17 Jul 1999 04:00:00




> : In the /var/spool/mqueue directory I am getting files with names like
> : xfPAA16888 (along with the normal qfPAA16888 and dfPAA16888). When I
> : get the "xf" files, mail is not delivered. The contents of the "xf"
> : files are similar to:

> : bellmail: error closing file: Permission denied
> : /usr/spool/mail/spaceadm.lock: Permission denied
> : /usr/spool/mail/spaceadm.lock: Bad file number
> : /usr/spool/mail/spaceadm.lock: Bad file number
> : .
> : . (keeps repeating the same line over and over)
> : .
> : /usr/spool/mail/spaceadm.lock: Bad file number

> : In /tmp, there exists a temporary file that always starts with ma
> : (e.g., mabq6Ma) that contains the message that you would expect in
> : /var/spool/mail. That is, it looks like:

> : From joe Sun Jul 11 15:41:02 1999

> : receivehostname.domainname (AIX4.2/UCB
> : 8.7/8.7) with SMTP id PAA16888 for <spaceadm>; Sun, 11 Jul 1999
> : 15:40:42 -1000 (HST)
> : Date: Sun, 11 Jul 1999 15:40:42 -1000 (HST)
> : From: "Sender's Name" <joe>

> : To: spaceadm
> : Subject: test

> : test

> : What would cause the "xf" file with the bellmail error?

> : Note: /usr/spool/mail is NFS mounted. /etc/exports on the NFS server
> : has the root option set (e.g., /usr/spool/mail
> : -root=hosta:hostb:hostc). If I unmount /usr/spool/mail, the problem
> : goes away but I would really like to understand what the root cause
> : is. I would like to keep the mail directory NFS mounted so that users
> : can access their mail (common directory) from any host (e.g., hosta,
> : hostb or hostc from the example /etc/exports above).

> The xf* file is the transcript of the session associated with that
> message ID.  The "Bad file number" error indicates that the bellmail
> process is trying to unlock and close a file which has been removed.
> I don't know whether the 'Permission denied' error is because bellmail
> is running as root and root doesn't have permission to write to the
> mount, or because the file has been removed.  (Both of these don't
> quite fit: I do see that you have exported the directory with the
> root option for this host; I don't see how a 'Permission denied'
> error would come from trying to close a file that has been removed
> unless it were locked by another process, but even there 1) your
> client doesn't know the inode of the file (see below) and 2) I
> suspect -- perhaps wrongly -- that bellmail does respect advisory
> file locking, which -- if correct -- would likely mean that
> it would sleep waiting for the lock to be freed.)

> More precisely, the inode number of the file has changed even
> though the name is the same.  The RPC packets that the client's
> biod sends to the server contain a filehandle which consists
> of -- if my memory serves me right -- the major and minor numbers
> of the block device on the server on which the file resides and
> the file's inode number.  The nfsd on the server receieves the
> request, interprets it and passes it on to the kernel.  The kernel
> returns the "Bad file number" error to its nfsd when it finds that
> the inode is neither in its inode cache or on disk, and the nfsd
> returns the error to the client biod via RPC.

> But this doesn't solve your problem.

> Does the entry for /usr/spool/mail in /etc/exports appear exactly
> as you described?

Yes

Quote:> Are those all of the options listed?

Yes, those are all the options in /etc/exports. The /etc/filesystems
on the clients are set to bg,intr.

Quote:> Also (and
> I'm not questioning your abilities here) can you confirm that the
> root option is actually in effect?  Can root on the client create
> a file in /usr/spool/mail?

Yes, the root option is actually in effect. I can log into the client
as root, cd to /usr/spool/mail and touch testfile.

Quote:> I've never spent time debugging NFS file locking (which is done by
> rpc.lockd and rpc.statd, which should be running on the client).
> The least I can say is that you should make sure that you've got the
> latest NFS, networking and kernel code for AIX 4.2.x (whatever you
> happen to be running, it better be 4.2.1. :)  In other words, there
> may be a locking problem with NFS at AIX 4.2.1, but I have no idea
> whether that's *really* the direction you should take to get your
> mail system working as desired.

I am on the current "maintenance level" 4210-04 (as IBM calls it).

Quote:> You may want to get _Managing NFS and NIS_, by Hal Stern, who works
> or used to work for Sun and is clearly an expert on these matters.

> The book contains a section on centralizing mail services with NFS
> and (gasp) NIS (but NIS is not required to get it working as he
> suggests).  It appears that the recommended way of doing this is
> to export the mail spool to the client for reading purposes only
> (the mount should be rw,hard, which are the defaults with AIX 4.2
> unless you specify otherwise), and have all mail forwarded to the
> mail hub.  That is, no mail will be delivered locally.

That may be the key. I'll try the mail hub approach. Thanks!

- Show quoted text -

Quote:> This is what I got out of a glance at that section of the book, so
> don't take my word for it.  Also, someone more knowledgable in
> these matters than I may have more and better things to say about it.

> Whatever the case,

> Best wishes,

> Nicholas

 
 
 

bellmail error - why?

Post by Geral » Mon, 19 Jul 1999 04:00:00





> : : In the /var/spool/mqueue directory I am getting files with names like
> : : xfPAA16888 (along with the normal qfPAA16888 and dfPAA16888). When I
> : : get the "xf" files, mail is not delivered. The contents of the "xf"
> : : files are similar to:

> : : bellmail: error closing file: Permission denied
> : : /usr/spool/mail/spaceadm.lock: Permission denied
> : : /usr/spool/mail/spaceadm.lock: Bad file number
> : : /usr/spool/mail/spaceadm.lock: Bad file number
> : : .
> : : . (keeps repeating the same line over and over)
> : : .
> : : /usr/spool/mail/spaceadm.lock: Bad file number

> : : In /tmp, there exists a temporary file that always starts with ma
> : : (e.g., mabq6Ma) that contains the message that you would expect in
> : : /var/spool/mail. That is, it looks like:

> : : From joe Sun Jul 11 15:41:02 1999

> : : receivehostname.domainname (AIX4.2/UCB
> : : 8.7/8.7) with SMTP id PAA16888 for <spaceadm>; Sun, 11 Jul 1999
> : : 15:40:42 -1000 (HST)
> : : Date: Sun, 11 Jul 1999 15:40:42 -1000 (HST)
> : : From: "Sender's Name" <joe>

> : : To: spaceadm
> : : Subject: test

> : : test

> : : What would cause the "xf" file with the bellmail error?

> : : Note: /usr/spool/mail is NFS mounted. /etc/exports on the NFS server
> : : has the root option set (e.g., /usr/spool/mail
> : : -root=hosta:hostb:hostc). If I unmount /usr/spool/mail, the problem
> : : goes away but I would really like to understand what the root cause
> : : is. I would like to keep the mail directory NFS mounted so that users
> : : can access their mail (common directory) from any host (e.g., hosta,
> : : hostb or hostc from the example /etc/exports above).

> <stuff deleted>

> : You may want to get _Managing NFS and NIS_, by Hal Stern, who works
> : or used to work for Sun and is clearly an expert on these matters.

> : The book contains a section on centralizing mail services with NFS
> : and (gasp) NIS (but NIS is not required to get it working as he
> : suggests).  It appears that the recommended way of doing this is
> : to export the mail spool to the client for reading purposes only
> : (the mount should be rw,hard, which are the defaults with AIX 4.2
> : unless you specify otherwise), and have all mail forwarded to the
> : mail hub.  That is, no mail will be delivered locally.

> : This is what I got out of a glance at that section of the book, so
> : don't take my word for it.  Also, someone more knowledgable in
> : these matters than I may have more and better things to say about it.

> : Whatever the case,

> : Best wishes,

> : Nicholas

> Sendmail's bad behavior when it tries to lock files in an NFS-mounted
> spool directory seems, from my experience, to be a "feature" that was
> introduced in the sendmail v8.7 that was delivered with AIX 4.2 and
> continued in sendmail v8.8 in AIX 4.3.  The sendmail v5.6 in AIX 3.2.5
> ans AIX 4.1 doesn't exhibit this behavior.  I "re-looked at" the O'Reilly
> "bat" sendmail book and the "porcupine" NFS/NIS book after reading your
> post.  I'd been struggling with the same problem situation for a while,
> but I had been assuming it was an NFS incompatibility problem between my
> AIX 4.1.5 mail spool NFS server and my new AIX 4.3.2 clients.  Your post
> got me on the right track, thank you.

> The "bat" book seems to hint that a file locking problem is likely to
> occur, but it doesn't say why in terms that I understand.  It's
> references to the flock(2) and fcntl(2) system calls don't strike a note
> of recognition in my brain.  Can someone with more experience post a
> more definitive explanation of what's going wrong when the spool
> directory is NFS-mounted?

> The suggestions on how to implement the mail hub in Stern's "porpcupine"
> book seem to be based on a sendmail.cf from an earlier version of
> sendmail than I.B.M. delivers with AIX 4.2 and 4.3.  The second edition
> of the "bat" book matches versions nicely with AIX 4.3.2.  I understood
> it to suggest the use of the "H" macro to define a mail hub (i.e.
> "DHnfs_server").  My mail configuration has no "MX" records and no entries
> in /etc/aliases, and I have reasonable assurance that all login-ids on
> the NFS clients are known on the NFS server for the spool directory.  I
> was already using "DS" to get mail sent off-local-network.  I left "DR"
> null (the default) and added "DHnfs_server".  Is this sufficient to get
> all mail forwarded to the NFS spool server, or have I shot myself in
> some other foot?  Some of my concern comes from the fact that although
> I can see the "H" macro being used in sendmail.cf, there isn't a
> nulled or commented out line inviting its use like there is for "R" and
> "S".

I used the "R" macro in the client sendmail.cf files and everything
works now. "Local" mail is not processed directly on the client but is
instead sent to the server. The server recognizes the user as being
local and writes to /usr/spool/mail without problems. The clients can
read mail from the NFS mounted server:/usr/spool/mail directory.

BTW, my server is running 4.1.5 (4150-01) and the clients are running
4.2.1 (4210-04).

 
 
 

1. Problem with /bin/bellmail on AIX 3.1

This should be a very simple and some of you might have encountered before.
I was using the standard .cf file from IBM and have my /usr/spool/mail
mounted from
a fileserver.  We shares our /usr/spool/mail directory among all our
workstations.
I tried to send a message to another local user on the same NIS (YP)
database. Below is the verbose
output that I got. It appeared to me that bellmail has problem writing
to a NFSed directory. It didn't help
even if I gave root access to the workstation on the fileserver.
I umounted the /usr/spool/mail and the message went fine.

The solution I am using now is to forward all the mail messages
(including local message) to the mail
server.  It also seems working fine since it is not using /bin/bellmail at all.

Any pointers and ideas are welcome.

Thanks

Eldon Chan
------------------------------------------------------------------------
----------------------------

cad610 267> mail -v bsriniv
Subject: test
ignore
.
Cc:
echan... setsender: uid/gid = 1555/1550
bsriniv... Connecting to .local...
bsriniv... Connecting to  (local)...
bsriniv... openmailer: DefUid 1, DefGid 1
bsriniv... openmailer: set ctladdr uid/gid 1555/1550
bsriniv... execve: uid = 1555, gid = 1550
bellmail: cannot append to /usr/spool/mail/bsriniv
Mail saved in /home/unx/echan/dead.letter
bsriniv... unknown mailer error 1

2. Star Office 5.0 questions

3. bellmail config info

4. Help me !!

5. Splitting up mail spool into subdirectories - bellmail question

6. Very basic question about tr/vi/ ...

7. bellmail and mail

8. Having a hard time updating by pre-patch

9. Problem with /bin/bellmail

10. bellmail and delivery problem

11. bellmail+quota

12. Why "xinit: Unknown error (errno 0): Client error."?

13. Telnet & FTP lag - why why why???