Zsh Mailing List Archive
Messages sorted by:
Re: Issues with fcntl() history file locking
- X-seq: zsh-workers 44093
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Philippe Troin <phil@xxxxxxxx>
- Subject: Re: Issues with fcntl() history file locking
- Date: Wed, 27 Feb 2019 13:27:37 -0800
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ySejXxmsecVK8GiwsStau/0PA0FIDW6GCyEOPoXp2zk=; b=UHPAEyNrYdW6I9mssUqNxyEKnctmE1VTm/yLaiSNaC6hcvRUWJFPsu79vIROy1Lm7n rH3TH76prj2gC5wyr6hNPD+5/nESh71UdyO4ImjORSxcnbvEL0UJWGFR3PPuPDrJc8wa neu2R6PE4/DyAQlXrF5rsyrYB0h+CCdQsGMrhJe9FRm6Pxgyu0d4ohxxA79l3atIUzQm iGZ961hTq9zepbVYLbNJKpwtI5VfDUK/1bFErgd2rkZ1TnnN8tiZYw5kAFsvBMdoiorP 4l0RBEKLDfnAEfDkQ+TdMIYaH/QSYVPL5hHJF5te2gvrnqMrtF7Sc1mOgMxkdst7NAdM ruXg==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-unsubscribe: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org>
On Wed, Feb 27, 2019 at 10:31 AM Philippe Troin <phil@xxxxxxxx> wrote:
> I've been using zsh with share_history for many years and never had any
> real issues on several networks where my home directory is mounted over
> NFS. Recently, it's been giving me trouble, maybe when I bumped up my
> history file size to 10k entries.
> I then discovered hist_fcntl_lock, which I had not ever set, and turned
> it on. It didn't improve anything.
Well, it wouldn't ... in fact it would likely make things worse.
flock() historically doesn't work reliably over NFS, and if you turn
that option on you are disabling the symlink-based file locking that
is usually more NFS-friendly. We used to do both kinds of locking
when hist_fcntl_lock, but workers/32580 reverted to using only one
kind ... I forget why I was asked to do that, probably something not
working as fast as was desired.
> Unfortunately, POSIX states that the fcntl() lock will be released upon
> the closing the first descriptor to the file. [...and thus...]
> * writehistfile writes the history file without lock
If that were the problem, you'd be likely to see corrupted entries
(the read stopping somewhere in the middle of what's being written) or
problems when both shells were writing to the file, which would also
likely manifest as corrupted entries.
Do the entries from terminal 1 NEVER show up in the file? Are they in
the file but never show up in the history of terminal 2? Or are they
just slow to arrive in terminal 2?
I'd be more inclined to suspect async NFS issues rather than locking.
Have you strace'd both processes to see when writes v. reads are
> 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.
Messages sorted by: