HP3000-L Archives

October 2004, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Johnson, Tracy" <[log in to unmask]>
Reply To:
Johnson, Tracy
Date:
Tue, 12 Oct 2004 14:43:00 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
Number 3 looks like a winner!
(Success is measured easily here.)

BT


Tracy Johnson
MSI Schaevitz Sensors 

> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of Emerson, Tom
> Sent: Tuesday, October 12, 2004 2:14 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Sendmail Delay?
> 
> 
> Two possibilities [maybe even more...]
> 
>    1) Mark only noted this was the "recommended" file 
> permissions -- if you know and understand the risks 
> associated with a less-than-secure setup, then by all means 
> change it so "normal" users could "check" the queue [this may 
> require a bit more in-depth knowledge of sendmail than you or 
> your users are willing to deal with, however...]
> 
>    2) make an SM monitoring JOB -- the part that is CHECKING 
> to see "is the queue emptying fast enough?" is the part that 
> needs SM.  Of course, if it isn't emptying, then you have to 
> figure out an ALTERNATE way of notifying you (perhaps by 
> pager?) since sending an e-mail saying "hey, the queue is 
> backed up" won't really be all that effective, now will it? ;) 
> 
>    3) just do a listf against /var/spool/mqueue (or 
> wherever...) and count the number of files in that directory 
> -- if non-zero, things are not clearing out...  (in other 
> words, you don't need to know what is "in" the directory, 
> just the fact that there ARE files there and they ARE NOT 
> going away)  A pure count of files may be too simplistic if 
> the number of e-mails sent at any given time is excessive (in 
> other words, every time you check there are one or more 
> files, just not the SAME files)  So a "fancier" way might be 
> to do a listf of just the filenames into a temp file on the 
> first pass, then on the second pass another listf followed by 
> a compare between the two files -- if files persist from one 
> pass to the next, then you know they are not clearing...
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2