Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Break connection?

7 views
Skip to first unread message

N

unread,
Feb 17, 2022, 7:05:09 AM2/17/22
to
When alpine is struggling to connect to a server, it gives the message

No reply in 15 seconds from server ...

and hangs. After 60 seconds, it briefly gives the option

Break connection?

However, if one misses the chance to break connection, one has to wait
another minute for the option to appear again.

When this happens, I usually just "pkill alpine" in another terminal.

I was wondering if there is a neater way of interrupting alpine?

Eduardo Chappa

unread,
Feb 17, 2022, 10:07:07 AM2/17/22
to
dear N,

what I do is to set timeouts much lower, so that I will not have to wait
for a long time. The easiest way to do this is to directly edit the
.pinerc file and reduce the tcp-*-timeouts to lower numbers. I have these
set up as follows:

# Network read warning timeout. The default is 15, the minimum is 5, and the
# maximum is 1000.
tcp-read-warning-timeout=6

# Network write warning timeout. The default is 0 (unset), the minimum
# is 5 (if not 0), and the maximum is 1000.
tcp-write-warning-timeout=15

I hope this helps.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

N

unread,
Feb 17, 2022, 2:42:08 PM2/17/22
to
Thanks for this (and, more generally, thanks very much for maintaining
Alpine)!

Carlos E.R.

unread,
Feb 19, 2022, 4:00:09 PM2/19/22
to
This has a problem. When doing a long operation (I think it is a search
running on the server), I have to say yes to continue several times,
because the server is indeed busy.


--
Cheers, Carlos.

Eduardo Chappa

unread,
Feb 19, 2022, 5:15:54 PM2/19/22
to
On Sat, 19 Feb 2022, Carlos E.R. wrote:

> This has a problem. When doing a long operation (I think it is a search
> running on the server), I have to say yes to continue several times,
> because the server is indeed busy.

TLDR: If you know why you have a timeout, you can ignore it or keep the
connection open until the operation completes.

I agree that there are problems. The problem really stems from having this
option at all. You can either programmatically close a connection when it
does not reply automatically, or you can have the user tell you when too
much is too much. Apline does the latter, and the problem with this is
that some operations are slow (sorting, searching, etc.) and for them you
will probably timeout in some moment. It is hard for anyone to distinguish
if the delay is due to a bad connection or a slow operation.

Because of that, I never answer the timeout question the first time when I
am doing a slow operation, and just let Alpine continue, or always answer
no, if I feel I need to. If the operation takes too long I will interrupt
the operation, but most times I do not have to do anything. I just know
that I might get the question about breaking the connection closed and
just simply ignore it.

Carlos E.R.

unread,
Feb 24, 2022, 8:57:10 AM2/24/22
to
The problem (from my point of view) is that you can not interrupt it at
will, any second. Just have it run continuously, no questions, but allow
to interrupt any second, not having to wait for the next prompt window.

--
Cheers, Carlos.

Eduardo Chappa

unread,
Feb 24, 2022, 11:04:29 PM2/24/22
to
On Thu, 24 Feb 2022, Carlos E.R. wrote:

> The problem (from my point of view) is that you can not interrupt it at
> will, any second. Just have it run continuously, no questions, but allow
> to interrupt any second, not having to wait for the next prompt window.

I agree. That's why I recommend to keep the timeouts low and use your best
judgement to try to figure out if a timeout is because of a broken
connection or a slow operation in the server.
0 new messages