From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 1475 invoked from network); 16 Jul 2021 18:33:03 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 16 Jul 2021 18:33:03 -0000
Received: from 5ess.inri.net ([107.191.111.177]) by 1ess; Fri Jul 16 14:06:11 -0400 2021
Message-ID: <9638F9EE898153F8D19FCE2F8E0DBBEC@5ess.inri.net>
Date: Fri, 16 Jul 2021 14:06:11 -0400
From: sl@stanleylieber.com
To: 9front@9front.org
In-Reply-To: <20210716105048.6a921b17@x1c.home.jtm.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: flexible ACPI table content-driven reduce/map storage 
Subject: Re: [9front] Unreliable delivery
Reply-To: 9front@9front.org
Precedence: bulk

> Looks like the issue hasn't happened again, so unfortunately I don't
> have any trace.  Here are some more detailed logs from the original
> issue.

thanks.  of course the transient nature of these failures makes
nothing any easier.  i've not yet figured out a good way to rig up
logging that can capture exactly where things are going long (or even
to examine the logging i've already captured, in depth).

(help appreciated)

in the meantime, i've added bind /net /net.alt to the cron-spawn runq
as well as the listeners for incoming mail.  as ori suggested, this
gives us a free retry.  subjectively, the queue is processing more
efficiently since this change.

sl