Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 May 2000 10:26:12 +0200
From:      Marc Silver <marcs@draenor.org>
To:        "Jon O @ kc" <jono@microshaft.org>
Cc:        Rahul Siddharthan <rsidd@physics.iisc.ernet.in>, Peter Losher <Peter.Losher@nominum.com>, freebsd-questions@FreeBSD.ORG
Subject:   Re: Pine "on hold" when sending (anyone ever have this problem)
Message-ID:  <20000504102612.K80532@draenor.org>
In-Reply-To: <Pine.BSF.4.10.10005031225340.65791-100000@stuart.microshaft.org>; from jono@microshaft.org on Wed, May 03, 2000 at 12:31:53PM -0700
References:  <20000503232858.A727@physics.iisc.ernet.in> <Pine.BSF.4.10.10005031225340.65791-100000@stuart.microshaft.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Another option you might want to try is to "truss" the process to see
what system calls it's making when it gets stuck.  Perhaps that can help
you find the solution.

Cheers,
Marc

On Wed, May 03, 2000 at 12:31:53PM -0700, Jon O @ kc wrote:
> I think this has to do with pine attempting to confirm it can find the
> user or the domain or maybe just the upstream mail server. No matter what
> it is, I would treat it as an indication that something is not running
> very well on your network, or just a general slowness. You may want to
> find out what's up before just settling for the below fix.
> 
> Go into the config and look at this item:
> 
> 
>         FEATURE: enable-background-sending
>  
> This feature affects the behavior of Pine's mail sending.  If set, this
> feature enables a subcommand in the composer's "Send?" confirmation
> prompt.  The subcommand allows you to tell Pine to handle the actual
> posting in the background.  While this feature usually allows posting
> to appear to happen very fast, it has no affect on the actual delivery
> time it takes a message to arrive at its destination.
>  
> NOTE 1: This feature isn't supported on all systems.  All DOS and Windows,
>         as well as several Unix ports, do not recognize this feature.
>  
> NOTE 2: Error handling is significantly different when this feature is
>         enabled.  Any message posting failure results in the message
>         being appended to your "Interrupted" mail folder.  When you
>         type the "Compose" command, Pine will notice this folder and
>         offer to extract any messages contained.  Upon continuing a 
>         failed message, Pine will display the nature of the failure 
>         in the status message line.
>  
> WARNING: Under extreme conditions, it is possible for message data to
>          get lost.  Do not enable this feature if you typically run close
>          to any sort of disk-space limits or quotas.
>  
> <End of help on this topic>
> 
> 
> Thanks,
> Jon
> 
> 	http://www.networkcommand.com
> 	No more Digital Voodoo.
> 
> 
> 
> 
> 
> On Wed, 3 May 2000, Rahul Siddharthan wrote:
> 
> > > I am not really sure if this is a Pine issue, FreeBSD issue, or a Postfix
> > > issue.  Our organization has 10 or so users running Pine (4.21) on a 
> > > FreeBSD v3.4-STABLE box under Postfix.  Every once in awhile, when someone
> > > sends a message, Pine will sit there on "Sending"... anywhere from 5-15
> > > minutes.  Looking at the maillogs, Postfix grabbed the message and sent it
> > > to the messages final destination all within 15 seconds.  So why would Pine
> > > just sit there "on hold" waiting?  (It happens sporadically at best (once
> > > or twice a day), enough to be an annoyance)
> > 
> > I have no clue about it, but would like to know the answer. The same
> > thing happens on a linux box we have (Red Hat 6.0) running the stock
> > sendmail.  It seems to happen most when there's a network problem and
> > the nameserver / the mail relay upstream can't be contacted. It
> > doesn't happen with elm or mutt on the same box.  It doesn't happen
> > with pine on other boxes on the same network running linux/freebsd and
> > qmail.  I don't think it happened on the freebsd box when it was
> > running sendmail, but that was ages ago and I'm not sure now.  I had
> > assumed that it was a problem with the sendmail config on the above
> > mentioned box (it's waiting for host lookups to timeout, or something)
> > and I've been suggesting to the administrator of that box to switch to
> > qmail, since at least it's easy to configure.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000504102612.K80532>