From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alexander Shukaev Newsgroups: gmane.emacs.devel Subject: Re: Emacs Hangs on Filesystem Operations on Stale NFS Date: Wed, 13 Jun 2018 12:45:35 +0200 Message-ID: <1250e91f-c46a-68f8-d5f9-0c4f7e40a5a9@Alexander.Shukaev.name> References: <1727545582523435cab149c2bc857b40@alexander.shukaev.name> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1528886624 409 195.159.176.226 (13 Jun 2018 10:43:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2018 10:43:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 12:43:40 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fT3Fb-0008Rf-UG for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2018 12:43:40 +0200 Original-Received: from localhost ([::1]:33161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT3Hj-0001Sp-3E for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2018 06:45:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fT3Hb-0001RV-Lp for emacs-devel@gnu.org; Wed, 13 Jun 2018 06:45:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fT3HY-0008SO-IW for emacs-devel@gnu.org; Wed, 13 Jun 2018 06:45:43 -0400 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:43737) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fT3HY-0008OJ-86 for emacs-devel@gnu.org; Wed, 13 Jun 2018 06:45:40 -0400 Original-Received: from [192.168.2.109] (dslb-188-097-130-202.188.097.pools.vodafone-ip.de [188.97.130.202]) (Authenticated sender: forum@alexander.shukaev.name) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 7FBC710001E for ; Wed, 13 Jun 2018 10:45:36 +0000 (UTC) In-Reply-To: <1727545582523435cab149c2bc857b40@alexander.shukaev.name> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.178.231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226285 Archived-At: On 06/11/2018 12:27 PM, Alexander Shukaev wrote: > Hi Everyone, > > > I initiated a discussion back in 2015 [1] about fragility of Emacs in > terms of filesystem operations on stale NFS.  No solution actually came > out of this discussion.  I still find this issue very disruptive.  Yet > another example would be `recentf-cleanup' which is in my case triggered > on Emacs start up, when the file comes from stale NFS, the corresponding > `file-readable-p' down the stack will hang indefinitely, and there would > be no way to unfreeze it apart from issuing 'kill -9' to that Emacs > instance.  Don't you people find it unacceptable for the daily usage? > Well, I do.  Such hangs always disrupt daily work and require quite some > time to track them down as they are not Lisp-debuggable with e.g. > in a straightforward way (these are dead hangs from C code, where even > attaching a GDB does not work). > > Well, enough rant.  I think I have a proposal how to fix the issue, even > given the blocking nature of Emacs.  How about introducing a variable > `file-access-timeout' defaulting to `nil', which would reflect a > configurable timeout for all access operations (such as > `file-readable-p')?  This would be achieved via `SIGALARM' in the C > code, which would protect every such operation.  For example, > > #include > #include > #include > #include > > static void alarm_handler(int sig) > { >     return; > } > > int emacs_stat(const char* path, struct stat* s, unsigned int seconds) > { >     struct sigaction newact; >     struct sigaction oldact; > >     memset(&newact, 0, sizeof(newact)); >     memset(&oldact, 0, sizeof(oldact)); > >     sigemptyset(&newact.sa_mask); > >     newact.sa_flags   = 0; >     newact.sa_handler = alarm_handler; >     sigaction(SIGALRM, &newact, &oldact); > >     alarm(seconds); > >     errno                 = 0; >     const int rc          = stat(path, s); >     const int saved_errno = errno; > >     alarm(0); >     sigaction(SIGALRM, &oldact, NULL); > >     errno = saved_errno; >     return rc; > } > > where `seconds' should be initialized with the value of > `file-access-timeout'.  The cool advantage of this that I see is that > one can then also selectively `let'-bind different values for > `file-access-timeout', thus having total control over the use cases in > which one wants to protect oneself from indefinite hangs. > > Kind regards, > Alexander > > [1] https://lists.gnu.org/archive/html/help-gnu-emacs/2015-11/msg00251.html > Today I realized that the following code import os import signal class Alarm(Exception): pass def alarm_handler(signum, frame): raise Alarm path = '/mnt/' signal.signal(signal.SIGALRM, alarm_handler) signal.alarm(3) try: os.stat(path) signal.alarm(0) except Alarm: print("Timed out after 3 seconds...") does not time out in case of 'hard' mounting, which means that the only way to time this case out reliably is to spawn a child which attempts to perform 'stat' and is then killed by the parent if timed out (similar to how 'lsof' does it). I'm sure such a complex technique would be unacceptable for Emacs. Although I don't like the current behavior as it looks like an editor vulnerability to me, which could be (either intentionally or unintentionally) used as a potential attack to hang the editor merely by pulling a network plug out, I have to admit that we can probably wrap up this discussion here since there is not much that could be done by Emacs itself to defend. Regards, Alexander