[comp.sys.sgi] mailbox

mjz@texhrc.UUCP (Michael Zeitlin) (09/22/90)

   i have 3.3 running on my 4D-25 personal iris and can't seem
   to get mailbox to work....i get the icon (and the nice flag going up)
   but my wsh scrolls continuously the following message:

    mailbox: Bad file number
    mailbox: Bad file number
    mailbox: Bad file number
    mailbox: Bad file number
    mailbox: Bad file number
    mailbox: Bad file number

   any ideas what's happening??

   i can use mail....to get to and from my sun network and the outside
    world, but cant seem to get the iris mail to work locally...
    i.e.  i can only read my mail on other systems ...

    michael Zeitlin....


    p.s. i've only now tried to use mail on 3.3...

robertl@cwi.nl (09/23/90)

	> mailbox: Bad file number
	> mailbox: Bad file number
	> mailbox: Bad file number
	> mailbox: Bad file number

	> any ideas what's happening ??

We had that too. In our case 'fam' couldn't be launched by
'inetd' properly. Try executing '/usr/etc/fam' manually. It
will probably print some additional info as to what is going on
(in our case 'fam' couldn't open /dev/imon). You will probably be
ok if you can get 'fam' to work.

By the way : if you are using central mail services you should
consider doing something like :
	
	$ ln -s $HOME/.mail /usr/spool/mail/$LOGNAME
	$ mailbox -f $HOME/.mail

This is because every second or so 'fam' will do an 'ls -l' 
of the directory in which your mail-file is in. 
In our case we had +/- 15 users doing an ls -l in /usr/spool/mail 
(which has +/- 250 entries) resulting in a substantial load on 
the central mail server! Making a link to your mail-file from a 
small directory results in a lot less network traffic. 



Groetjes;

-- Robert van Liere

------------------------------------------------------------
Robert van Liere, Department of Interactive Systems,
Center for Mathematics and Computer Science (CWI)
Kruislaan 413,  1098 SJ  Amsterdam,  The Netherlands
robertl@cwi.nl

bennett@sgi.com (Jim Bennett) (09/24/90)

In article <501@texhrc.UUCP> mjz@texhrc.UUCP (Michael Zeitlin) writes:
>
>
>   i have 3.3 running on my 4D-25 personal iris and can't seem
>   to get mailbox to work....i get the icon (and the nice flag going up)
>   but my wsh scrolls continuously the following message:
>
>    mailbox: Bad file number
>    mailbox: Bad file number
>    mailbox: Bad file number
>    mailbox: Bad file number
>    mailbox: Bad file number
>    mailbox: Bad file number
>
>   any ideas what's happening??

Mailbox prints this message when it can't connect to fam.  You should
check if famd is running.

>   i can use mail....to get to and from my sun network and the outside
>    world, but cant seem to get the iris mail to work locally...
>    i.e.  i can only read my mail on other systems ...
>
>    michael Zeitlin....
>
>
>    p.s. i've only now tried to use mail on 3.3...

One of the network types should answer this one.  You could try "Mail -v",
to see where the mail is going.

Jim Bennett				(bennett@esd.sgi.com)

eva@socrates.esd.sgi.com (Eva Manolis) (09/25/90)

In article <9009222055.AA00571@paling.cwi.nl>, robertl@cwi.nl writes:
|> 
|> 	> mailbox: Bad file number
|> 	> mailbox: Bad file number
|> 	> mailbox: Bad file number
|> 	> mailbox: Bad file number
|> 
|> 	> any ideas what's happening ??
|> 
|> We had that too. In our case 'fam' couldn't be launched by
|> 'inetd' properly. Try executing '/usr/etc/fam' manually. It
|> will probably print some additional info as to what is going on
|> (in our case 'fam' couldn't open /dev/imon). You will probably be
|> ok if you can get 'fam' to work.
|> 
|> By the way : if you are using central mail services you should
|> consider doing something like :
|> 	
|> 	$ ln -s $HOME/.mail /usr/spool/mail/$LOGNAME
|> 	$ mailbox -f $HOME/.mail
|> 
|> This is because every second or so 'fam' will do an 'ls -l' 
|> of the directory in which your mail-file is in. 
|> In our case we had +/- 15 users doing an ls -l in /usr/spool/mail
|> 

I little info on 'fam' here....

fam will NEVER do an 'ls -l' of a directory. 
IF ( and only if) the directory is NFS mounted ( which seems to be 
the case for Robert van Liere ) 'fam' will 'stat' the directory to
track changes. If the files reside on a local file system, there is
no polling ( no 'stats' ). fam works with events generated when the filesystem
is changed, so it's as cheap and low overhead as it can be.
For NFS directories and files, the stat's are every 3 seconds.

As far as having trouble starting fam, since fam uses inetd if the
machine is having network problems, fam will have trouble starting.
Also, inetd uses YP, so if you have YP configured on, you need to make
sure that the YP server knows about the 'fam' service.
   ( a message will appear in /usr/adm/SYSLOG, to clue you in on fam problems)

To make sure YP is set up correctly, find out who your YP server is
   % ypwhich
    <some machine name here>

then, login onto your yp server, and make sure that the /etc/rpc file contains
a line in it that says  
    sgi_fam	391002

If it doesn't, add it.
Then ( as root )
	% cd /usr/etc/rpc; make

Everything should be ok now.

Have fun
-eva

eva@socrates.esd.sgi.com (Eva Manolis) (09/25/90)

In article <1990Sep24.174807.26980@odin.corp.sgi.com>, eva@socrates.esd.sgi.com (Eva Manolis) writes:
|> In article <9009222055.AA00571@paling.cwi.nl>, robertl@cwi.nl writes:
|> |> 
|> |> 	> mailbox: Bad file number 
|> |> 	> any ideas what's happening ??
|> |> 
|> |> We had that too. In our case 'fam' couldn't be launched by
|> |> 'inetd' properly. 
|> 
|> I little info on 'fam' here....
|> 
|> fam will NEVER do an 'ls -l' of a directory. 
|> IF ( and only if) the directory is NFS mounted ( which seems to be 
|> the case for Robert van Liere ) 'fam' will 'stat' the directory to
|> track changes. If the files reside on a local file system, there is
|> no polling ( no 'stats' ). fam works with events generated when the filesystem
|> is changed, so it's as cheap and low overhead as it can be.
|> For NFS directories and files, the stat's are every 3 seconds.
|> 
|> As far as having trouble starting fam, since fam uses inetd if the
|> machine is having network problems, fam will have trouble starting.
|> Also, inetd uses YP, so if you have YP configured on, you need to make
|> sure that the YP server knows about the 'fam' service.
|>    ( a message will appear in /usr/adm/SYSLOG, to clue you in on fam problems)
|> 
|> To make sure YP is set up correctly, find out who your YP server is
|>    % ypwhich
|>     <some machine name here>
|> 
|> then, login onto your yp server, and make sure that the /etc/rpc file contains
|> a line in it that says  
|>     sgi_fam	391002
|> 
|> If it doesn't, add it.
|> Then ( as root )
|> 	% cd /usr/etc/rpc; make
|> 

Sorry, I meant 
     	cd /usr/etc/yp; make
  ( and I've been informed, on new model suns, its
	cd /var/yp; make

|> Everything should be ok now.
|> 
|> Have fun
|> -eva

sjoerd@cwi.nl (Sjoerd Mullender) (09/25/90)

eva@socrates.esd.sgi.com (Eva Manolis) writes:

>fam will NEVER do an 'ls -l' of a directory. 
>IF ( and only if) the directory is NFS mounted ( which seems to be 
>the case for Robert van Liere ) 'fam' will 'stat' the directory to
>track changes. If the files reside on a local file system, there is
>no polling ( no 'stats' ). fam works with events generated when the filesystem
>is changed, so it's as cheap and low overhead as it can be.
>For NFS directories and files, the stat's are every 3 seconds.

Robert and I found together that a system on which mailbox was running
produced many requests to the mail server.  I just did a small test to see
what really happens.
I have a NFS directory with 2 symbolic links in it.  I told mailbox to
check one of these links.  My system produced the following sequence of
NFS requests with 3 second intervals:
(-> to server, <- from server)
	(nothing happend for 3 seconds)
	-> read symbolic link
	<- ok (path=/usr/spool/mail/sjoerd)		the link I'm checking
	-> get attributes
	<- ok
	-> read dir					why read the directory?
	<- ok (4 entries)
	-> read symbolic link
	<- ok (path=/usr/spool/mail/sjoerd)		why again?
	-> get attributes
	<- ok
	-> read symbolic link
	<- ok (path=/usr/spool/mail/robertl)		why? I'm not checking
	-> get attributes				  this file
	<- ok
	(nothing happens for 3 seconds)
I can understand the first two requests with their answers, but why all the
other requests?
--
Sjoerd Mullender		Center for Mathematics and Computer Science
sjoerd@cwi.nl			Amsterdam, Netherlands

mjz@texhrc.UUCP (Michael Zeitlin) (02/12/91)

   I use the mailbox tool everyday when I log in...
   Recently, when my mailbox started up, I noticed a repeating
   message:

   mailbox: bad file number
   mailbox: bad file number
   ......etc.

   mail still works...but the mailbox no longer functions.
   any ideas out there?

   Michael Zeitlin