From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 736106DE0C42 for ; Mon, 10 Sep 2018 07:20:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=0.197, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gKjPLy6XtYA for ; Mon, 10 Sep 2018 07:20:53 -0700 (PDT) Received: from filter01.roch.ny.frontiernet.net (filter01.roch.ny.frontiernet.net [66.133.183.226]) by arlo.cworth.org (Postfix) with ESMTP id 25D9A6DE0C3F for ; Mon, 10 Sep 2018 07:20:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by filter01.roch.ny.frontiernet.net (Postfix) with ESMTP id 887F479C33; Mon, 10 Sep 2018 14:20:50 +0000 (UTC) Received: from relay01.roch.ny.frontiernet.net ([66.133.182.164]) by localhost (filter01.roch.ny.frontiernet.net [66.133.183.226]) (amavisd-new, port 10024) with LMTP id M8afP5c_Bhq5; Mon, 10 Sep 2018 14:20:37 +0000 (UTC) X-Originating-IP: [50.39.167.193] X-Previous-IP: 50.39.167.193 Received: from beetle_b (50-39-167-193.bvtn.or.frontiernet.net [50.39.167.193]) by relay01.roch.ny.frontiernet.net (Postfix) with ESMTPA id 2E1533FCE; Mon, 10 Sep 2018 14:20:37 +0000 (UTC) Received: by beetle_b (Postfix, from userid 1000) id 3A0C61EA0204; Mon, 10 Sep 2018 07:21:11 -0700 (PDT) From: Mueen Nawaz To: David Bremner , xapian-discuss@lists.xapian.org, notmuch@notmuchmail.org Subject: Re: Notmuch DB Problems In-Reply-To: <87a7opk45p.fsf@tethera.net> References: <47409d4ed692a336458371102bcbcbd86ab4a067@webmail.nawaz.org> <874lf3es5a.fsf@nikula.org> <87tvn1e32k.fsf@nawaz.org> <87a7opk45p.fsf@tethera.net> Date: Mon, 10 Sep 2018 07:21:11 -0700 Message-ID: <874lexe8mg.fsf@nawaz.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailman-Approved-At: Mon, 10 Sep 2018 07:59:03 -0700 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 14:20:54 -0000 David Bremner writes: >> Here's why it would freeze: >> >> I have a post-new hook that runs a Python script. Depending on >> whether the new email it is processing matches a rule I have, >> it will fire off an email to the sender using the SMTP library >> in Python. >> >> I had recently upgraded my MTA (PostFix), and it had a backward >> incompatible change that broke my config. I don't know why, but >> I could still send emails via Emacs, but when I tried to send >> them via Python, Postfix would log an error and it would not >> send. The Python statement would freeze (I guess Postfix >> doesn't return an appropriate response? Not sure why). >> >> I have a cron job to run "notmuch new" 3 times an hour. Since >> the hook was frozen, so was the notmuch new command. I had >> quite a lot of "notmuch new" processes. I assume this meant the >> DB was locked all this time for writing. > > notmuch unlocks the database before running the hook, so I don't > understand how a hung hook results in a locked database. If it > happens again (or you're motivated to set up a testbed) I'd be > interested in the output of Well, it results in a locked database because I have this in the (Python) hook: DATABASE = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE) Soon after that I freeze the new messages. And at the end I thaw them out. The hang occurs in between the two, I think. > Also, is this by chance a network file system? Because those > often break locking. No - regular hard drive. >> Now killing all those jobs did not fix the database. It was >> still broken. And as we saw the second time round, it was >> /really/ broken - it would not even open in read-only mode. > > That seems like something the Xapian devs (in copy) might be > interested in fixing, if you could come up with a simple > reproducer. I can think of two experiments: 1. Write a hook that opens the database as above, and then just does nothing (e.g. while True). Let it run, say, for 24 hours. (Not sure if the "freeze" part is relevant. 2. Same as the above, but have a cron job that fires "notmuch new" every 20 minutes. This will freeze on the database line above (all except the first invocation which will be stuck at while True). After a day of this, check if you can open the database in READ_WRITE mode. > notmuch could be cleverer about timing out on trying to acquire > a lock. I suspect it's a bit delicate to get that right, and > I've been hoping the underlying primitives would get a bit more > flexible w.r.t. locking. I agree having notmuch handle it is not ideal. I was originally thinking there should be a default timeout that one can adjust as needed. However, when someone does "notmuch new" to build a new database, that can take several minutes. And others may have flows very different from mine. At the very least, we probably should know why the DB be clobbered at all. -- Don't take life so seriously. It won't last. /\ /\ /\ / / \/ \ u e e n / \/ a w a z >>>>>>mueen@nawaz.org<<<<<< anl