From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#49954: 28.0.50; TRAMP: cannot kill child processes: "Forbidden reentrant call of Tramp" Date: Sat, 11 Sep 2021 14:19:06 +0200 Message-ID: <878s03s3t1.fsf@gmx.de> References: <875ywf9ea7.fsf@secretsauce.net> <871r72ssqi.fsf@gmx.de> <874kby7wn5.fsf@secretsauce.net> <875ywdquds.fsf@gmx.de> <87pmtfjyw4.fsf@secretsauce.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37157"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 49954@debbugs.gnu.org To: Dima Kogan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 11 14:20:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mP1zO-0009RJ-Kx for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Sep 2021 14:20:10 +0200 Original-Received: from localhost ([::1]:45374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mP1zM-0008Vs-Lv for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Sep 2021 08:20:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mP1zG-0008Vj-EL for bug-gnu-emacs@gnu.org; Sat, 11 Sep 2021 08:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56351) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mP1zG-0005Xw-7C for bug-gnu-emacs@gnu.org; Sat, 11 Sep 2021 08:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mP1zG-0008Cx-2Z for bug-gnu-emacs@gnu.org; Sat, 11 Sep 2021 08:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Sep 2021 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49954 X-GNU-PR-Package: emacs Original-Received: via spool by 49954-submit@debbugs.gnu.org id=B49954.163136275931493 (code B ref 49954); Sat, 11 Sep 2021 12:20:02 +0000 Original-Received: (at 49954) by debbugs.gnu.org; 11 Sep 2021 12:19:19 +0000 Original-Received: from localhost ([127.0.0.1]:39664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mP1yZ-0008Bs-HG for submit@debbugs.gnu.org; Sat, 11 Sep 2021 08:19:19 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:54371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mP1yX-0008Bf-Ln for 49954@debbugs.gnu.org; Sat, 11 Sep 2021 08:19:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631362747; bh=bCOkM4GDz+jICNhw6nafAuwCYGF2w8WyEzJjZ284aLA=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=HIbCinORsjSdb+l8qSgcHUr4LjUshW/ktRrfcwjCISbrUDfk8AMT/weuaG/ikDBBS A375bmszMIwPzaUyJOseVo8I2I7t+50xCkO2qa7misFvXNZyqcDCS6fBPUKp2mb5DC m8XWJ6ZkuD4p8Gkr29Wg0LeZpY7pEW7s+V8UmPBY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([213.220.148.126]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MKKYx-1meD4e1wA3-00LjuO; Sat, 11 Sep 2021 14:19:07 +0200 In-Reply-To: <87pmtfjyw4.fsf@secretsauce.net> (Dima Kogan's message of "Sat, 11 Sep 2021 01:32:27 -0700") X-Provags-ID: V03:K1:kQAzV1VJgUtWN7ZMUsgEjMph8k+OWyXRfWpS1dnNtZpXFYREM6R uaaAsirSj3Rkf1wt2UbAIcnWGuy35HXMFn+EwTQvEbmHqtk2kigQ+GT7LAxvjDFGEvTPgwb jwTbY4663LpOYwaIgvJFLOtaE97STgw9aGGztRMWorbFo2i0s4Orwk21wGe3OLIfXO8N2zL XF+BE2RtwWq90lwy8RoYg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Qq40gcKe484=:D2Z1SaYkluRVhws0IMIwbK 6OWflJoImWKlDtU18tnW+RLnJjlpFSnnZsynMBWQ98Jbaepy70AxQLIlEKA4l8dFNZSPSHUl/ hLb60ZnzAMzzNoeHtHlaheN92dz0lH89Xw2cnKCU+UIlZoN7B0stXbwQS0kWLkD3ewGjnNg4f 6eBZ1XRJVEvT4H+3hM+1WE7XIrChb2oSEdgLZVQYVWNWE58dZgOuNT5l/Twu4vDcLGF84rktp 8hM65/7etP7mOejRilerJAadbWs9LVYJfz4HUedUbvnLL08GI/FjVmy6QyWgj38jWaXZSNdWX u8p8+eybOr6ZwUWopF5Mk2Od/EC2tD/yHOxbi+IAMHAayscyOkewkyDnLKd+mkGGKkTH1ZInf P5r8zHT83Or8SwBmxP3Lx8iOB08f8fH5W1YVbWIXgYRbEC5yGflt10fOL4wQhZp6XpUcVPhCA 1k4zjfjOOFQyEVjWzpiw6VAA4L9sQe158EEqI3m9JeKy8fVJ/avOcHqC0SFLczavPid9AHZgV zKwmovK6ajD5g0UhhXMXfIQ0sv3YeAyHFuwBlNT68J4stJOqE8VK8sZjtOqaZiZ2jwn6QoP+2 lgXCUEHWpaP8jnCMpRh867crM1atG7pq2IawWWnMZHD8yZ6zyRtspz+ZDGDUbNfoTUF77eaPW 8wS2whpR1XOX1EWKT+Hx+zDVVeBJNgh23uS8Y+sBbkKtLT0S+EGQcFcsOPlfLOG7/kbe3CJQg N86ISsIOQb7x8GCliabZxYrBiE0aU1jDTWYb9XDSGmWItW2Ze0uozGj4zK7g8YFPuQ2siGj0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214059 Archived-At: Dima Kogan writes: > Hi Michael. Hi Dima, > So I've seen this a number of times now, and it really looks like the > caching mechanism is the problem. No, it isn't. Tramp uses its cache just as memory. The problem is somewhere else, see below. > Every time I see "Forbidden reentrant call of Tramp" when trying to > C-c C-c a remote process, I re-evaluate tramp-get-connection-property > with > > (when (and (not (eq cached tramp-cache-undefined)) > ;; If the key is an auxiliary process object, check > ;; whether the process is still alive. > (not (and (processp key) (not (process-live-p key))))) > (setq value cached > cache-used t)) > > removed. This effectively disables the caching mechanism. Then I can C-c > C-c my process, and it dies like it's supposed to. TRAMP feels slower > after than, as expected, so I put tramp-get-connection-property back to > what it was. Eventually the problem comes back, and I do the same dance > to "fix" it. The Tramp manual tells you how to bypass the problem, see Frequently Asked Questions: --8<---------------cut here---------------start------------->8--- =E2=80=A2 I get an error =E2=80=98Remote file error: Forbidden reentrant= call of Tramp=E2=80=99 Timers, process filters and sentinels, and other event based functions can run at any time, when a remote file operation is still running. This can cause TRAMP to block. When such a situation is detected, this error is triggered. It should be fixed in the respective function (sending an error report will help), but for the time being you can suppress this error by the following code in your =E2=80=98~/.emacs=E2=80=99: (setq debug-ignored-errors (cons 'remote-file-error debug-ignored-errors)) --8<---------------cut here---------------end--------------->8--- In order to understand the problem, let's assume the following scenario: - You have connected to a remote host, say "/ssh:host:". Tramp uses internally the process *tramp/ssh host* for communicating with that process. - You have also started another asynchronous process to that remote host. - Now, while normal use of Emacs, the function (file-attributes "/ssh:host:/path/to/file") is called. Tramp sends a command to the process *tramp/ssh host*, like "stat /path/to/file". - While Tramp waits for the answer of the "stat ..." command, your other process has finished. It might have a process sentinel, which is called exactly at this time, because Tramp is in a loop (accept-process-output ...). - This process filter might trigger another file operation, like (delete-file "/ssh:host:/tmp/tmpfile"). This would require to send another command to the *tramp/ssh host* process like "rm -f /tmp/tmpfile". - Since the first command, "stat ...", hasn't been finished, this would result in inconsistencies. Tramp detects this situation, and raises the "Forbidden reentrant call of Tramp" error. Not so easy to solve. Ideally, remote file name functions initiated in process filters, process sentinels, timers and alike shall wait, until the currently executed remote command has finished. Don't know how to achieve this. Best regards, Michael.