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=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24780 invoked from network); 26 Aug 2020 21:01:43 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 26 Aug 2020 21:01:43 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1kB2XU-009zeu-Tm; Wed, 26 Aug 2020 16:01:00 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kB2XP-009zcz-RZ for ding@lists.math.uh.edu; Wed, 26 Aug 2020 16:00:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kB2XN-001PNy-Tn for ding@lists.math.uh.edu; Wed, 26 Aug 2020 16:00:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:References:In-Reply-To:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sh7ZGzh2tI8TdFfVnmf/anO3DRtXQvMU2K4v+4t3Amo=; b=YgkvECvQUvyWrVsXhkqf071EHg ejNkFjNl1aCxn5ioqbW+ASlj/32RXsvXtIxD7g0vNwif0ccGz3WAlF7R9JSyjrwj8I4ojNKdMLL0o Z2XuIpl3kvla5Yg8UGf/qmHt4Bb7tXLu4Z+MFuPANgRBHdae+ZpnsoAb06vN6UiOTQkQ=; Received: from haven.eyrie.org ([166.84.7.159]) by quimby with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kB2XD-0002eg-MY for ding@gnus.org; Wed, 26 Aug 2020 23:00:49 +0200 Received: from lothlorien.eyrie.org (unknown [IPv6:2603:3024:160b:400:ae22:bff:fe50:db06]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 77FB31186DA for ; Wed, 26 Aug 2020 14:00:41 -0700 (PDT) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 22FF5B43B6B; Wed, 26 Aug 2020 14:00:35 -0700 (PDT) From: Russ Allbery To: ding@gnus.org Subject: Re: nnml suddenly not activating groups on startup In-Reply-To: <87y2m1jnij.fsf@tullinup.koldfront.dk> ("Adam =?utf-8?Q?Sj?= =?utf-8?Q?=C3=B8gren=22's?= message of "Wed, 26 Aug 2020 20:00:20 +0200") Organization: The Eyrie References: <87zh6itacs.fsf@hope.eyrie.org> <871rjtn8g2.fsf@tullinup.koldfront.dk> <87tuwptjcx.fsf@hope.eyrie.org> <87y2m1jnij.fsf@tullinup.koldfront.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Date: Wed, 26 Aug 2020 14:00:34 -0700 Message-ID: <878se1dswd.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: Precedence: bulk Adam Sj=C3=B8gren writes: > All=C2=B9 of my mail groups have "nnml:" as the last element in > gnus-newsrc-alist. > I have a feeling that Gnus sometimes gets confused about servers that > are the same but mentioned by different definitions. Maybe going all > "nnml:" or all (nnml "") will unconfuse things? I tried changing everything to "nnml:" and that caused all of the groups to not be activated and then, in the server buffer, the nnml server was left closed after I started Gnus. I then changed them all to (nnml "") and that fixes the problem (but I suspect new groups won't have that setting). So (nnml "") seems to be doing something different than "nnml:" and is working correctly, and this appears to have something to do with when the server is opened. Maybe it's a sequencing issue during startup? For the record, my select-method configuration is: '(gnus-select-method '(nntp "news.eyrie.org" (nntp-open-connection-function network-only) (nntp-connection-timeout 3))) '(gnus-secondadry-select-methods '((nnml ""))) > Does your server buffer show multiple nnml-servers? It does not, but now that you mention this, I feel like at one point I did see this and "fixed it" by deleting one of the servers. I should have remembered that, and that's probably related, although I'm fairly sure my problems started before that and this was one of my attempts to fix it. > =C2=B9 Not my archive groups, though, they seem to all carry a copy of th= e full > server definition: > (nnml "archive" (nnml-directory "~/Mail/archive") > (nnml-active-file "~/Mail/archive/active") > (nnml-get-new-mail nil) > (nnml-inhibit-expiry t)) > as the last element. That seems a little much. Mine had this in gnus-server-alist and just a reference to "archive" in the group information, but while I've been working on this problem (and after it started), I finally got rid of the second nnml server for archiving and just merged all that stuff into my main nnml server because I've had no end of problems with having two nnml servers for years. It seems to confuse Gnus and I have regularly had Gnus write things into the archive server instead of the main server in weird edge cases. The last straw was that while I was restarting Gnus to try to get to the bottom of this problem, one time Gnus split all of my incoming mail into the archive server instead of the main nnml server. The multiple nnml server support seems kind of buggy, in other words, and has been for years, although it previously had never irritated me enough to change it. --=20 Russ Allbery (eagle@eyrie.org)