From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 0d9d200a for ; Sat, 9 Mar 2019 00:54:00 +0000 (UTC) Received: (qmail 23751 invoked by alias); 9 Mar 2019 00:53:46 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44105 Received: (qmail 22155 invoked by uid 1010); 9 Mar 2019 00:53:45 -0000 X-Qmail-Scanner-Diagnostics: from granite.fifsource.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25376. spamassassin: 3.4.2. Clear:RC:0(173.255.216.206):SA:0(-1.9/5.0):. Processed in 2.951895 secs); 09 Mar 2019 00:53:45 -0000 X-Envelope-From: phil@fifi.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at fifi.org designates 173.255.216.206 as permitted sender) Message-ID: <70520d027e2f5ddc09b2c78d543664b52341f450.camel@fifi.org> Subject: Re: Issues with fcntl() history file locking From: Philippe Troin To: Zsh hackers list Date: Fri, 08 Mar 2019 16:53:08 -0800 In-Reply-To: References: <717dfbf28e1b56d070ad0038f0367e3d2ab99464.camel@fifi.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit On Wed, 2019-02-27 at 22:36 -0800, Philippe Troin wrote: > On Wed, 2019-02-27 at 13:27 -0800, Bart Schaefer wrote: > > On Wed, Feb 27, 2019 at 10:31 AM Philippe Troin > > wrote: > > > > > > The right and hard way is to have the various calls to open() the > > > history file to actually use the flock_fd lock file descriptor > > > (and not close it when done with it, leaving that to > > > unlockhistfile()). > > > > > > The easy messy way is to keep track of all the open descriptors > > > to the history file in a global variable, and delaying the actual > > > close until unlockhistfile() is called. > > > > If this actually turns out to be necessary, the second way is more > > similar to how we handle descriptors in other parts of the shell. > > I'll do further experiments. > > This is my current hunch: everything is swell as long as lines are > appended to the history file. But, when one host decides it's time > to > trim the history file is when stuff hits the fan. If someone had an > idea on how to force zsh to trim history reliably, I'm all ears. So, I've implemented what I described (delaying closing the file descriptors and handles until unlock time). The rough patches will follow shortly. But, it doesn't help the problem at all: I've been running 5.7.1 + that patch on a small network, and I ran into the same issue again :-/ Back to the drawing board... It's something else that's happening. I'll let you decide if the patches are worth inclusion or not. Since it doesn't fix any actual issues, probably not, even though this is supposed to be more correct to avoid history corruption on network filesystems when hist_fcntl_lock is active. Phil.