From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17941 invoked by alias); 6 Sep 2014 09:03:58 -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: X-Seq: 33112 Received: (qmail 23238 invoked from network); 6 Sep 2014 09:03:53 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aoQVG4A14zsShZ4Gzr2Hl81S47KhHo/kqHlCbeWYmCU=; b=y6aoc5PMIOJEJuxeZvoD0ikdsmKSneo8waoc44VjswsL0/lb3BIn4PVOlC8f/4onlO IGnhfntnCHBo6+AUKUd3nbiHPLV1Acr1K14xbifG8yWUU5cq8pkSRG25Ao7ubyiU0gUw HZkRPq+B6Tw+mT2QEADbjPNHZBhiLj0Yxg8uRvcke5Hv5KBhXe/adtcSWbezg4YbNdOl o0kaUdSoEQe7r0mIfKijfR6EwbcC6fEGzX1kHcusarVIuJn0GBjQ27aK6sN63EYpfqxC edSlEhsOOu31uHrmkS68hm09AzMIdqjQMfdM2QOe1m9v1wuJi5LdgLZK/rpWZoEwmo6S 9lbw== MIME-Version: 1.0 X-Received: by 10.224.103.65 with SMTP id j1mr26306966qao.17.1409994228732; Sat, 06 Sep 2014 02:03:48 -0700 (PDT) In-Reply-To: References: <53594068.4040503@googlemail.com> <140424100228.ZM10689@torch.brasslantern.com> <140424220232.ZM11424@torch.brasslantern.com> Date: Sat, 6 Sep 2014 11:03:48 +0200 Message-ID: Subject: Re: zsh got stuck without any message because of history lock file From: Mikael Magnusson To: zsh workers Content-Type: text/plain; charset=UTF-8 On 26 June 2014 22:46, Mikael Magnusson wrote: > On 25 April 2014 07:02, Bart Schaefer 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. I'm still seeing reports of this every now and then in #zsh (and I have the option unset so I'm not sure if it happens to me anymore.) If nobody fixed this, it's probably still a problem. -- Mikael Magnusson