Re: zsh got stuck without any message because of history lock file

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 25 April 2014 07:02, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Apr 24, 10:02am, Bart Schaefer wrote:
> }
> } The way the code is currently written the shell will wait until 10
> } seconds after the modification time stamp of the file.  If for some
> } reason the time stamp is wrong (clocks out of sync with NFS server,
> } for example) then it may end up waiting for longer.
>
> So ... here is a patch that checks for future timestamps.  If it finds
> one, it leaves errno set to EEXIST, which results in:
>
> zsh: locking failed for /home/schaefer/.zhistory: file exists
>
> This isn't perfect, but at least it provides a clue.
>
> There's a controversial bit in this patch:  It appears HIST_FCNTL_LOCK
> may have been broken ever since workers/28047 in 2010.  That patch
> changed flockhistfile() [which is misnamed, it uses fcntl] to return 0
> on success, but then also this:
>
>         ret = flockhistfile(fn, keep_trying);
>         if (ret)
>             return ret;
>
> That means that we only stop when flockhistfile() FAILS.  On success,
> we go on and lock with BOTH fcntl AND a .LOCK file.  This completely
> contradicts the documentation claim that "this may provide better
> performance."  So the second hunk below makes flockhistfile() the
> only lock applied when HIST_FCNTL_LOCK is set.
>
> However, this would mean that every zsh that is accessing the same
> HISTFILE has to be using the same locking options.  Is that OK?

I'm not 100% sure it's because of this change, but recently, I've had
new terminals stuck forever on startup until I exit all open terminals
logged in as that user (or possibly just a specific one of them). It
happens very spuriously, maybe a few times per week. I have
histfcntllock set. On one occasion I tried moving the .history file
instead of exiting, and this also immediately unstuck all new
terminals.

-- 
Mikael Magnusson