From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?S=C3=A9bastien?= Gross Newsgroups: gmane.emacs.bugs Subject: bug#8929: 24.0.50; tramp hangs when process died Date: Mon, 27 Jun 2011 10:57:40 +0200 Organization: Chezwam Message-ID: <87r56fwt17.fsf@ubik.of1par.int.rtblw.com> References: <87tybf4b6l.fsf@ubik.of1par.int.rtblw.com> <87oc1l7zbp.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1309194995 30955 80.91.229.12 (27 Jun 2011 17:16:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Jun 2011 17:16:35 +0000 (UTC) Cc: =?UTF-8?Q?S=C3=A9bastien?= Gross , 8929@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 27 19:16:31 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QbFQE-00073N-QK for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jun 2011 19:16:30 +0200 Original-Received: from localhost ([::1]:41070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbFQD-0001XV-IW for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jun 2011 13:16:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbEkF-00073q-3M for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2011 12:33:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbEkC-0000ii-Rj for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2011 12:33:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53925) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbEkC-0000iX-H6 for bug-gnu-emacs@gnu.org; Mon, 27 Jun 2011 12:33:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QbEkB-0007oG-Vh; Mon, 27 Jun 2011 12:33:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?S=C3=A9bastien?= Gross Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Jun 2011 16:33:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8929-submit@debbugs.gnu.org id=B8929.130919233729943 (code B ref 8929); Mon, 27 Jun 2011 16:33:03 +0000 Original-Received: (at 8929) by debbugs.gnu.org; 27 Jun 2011 16:32:17 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QbEjP-0007mr-0U for submit@debbugs.gnu.org; Mon, 27 Jun 2011 12:32:17 -0400 Original-Received: from alawa.chezwam.org ([88.191.47.209]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Qb7dc-0007lD-Bp for 8929@debbugs.gnu.org; Mon, 27 Jun 2011 04:57:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=chezwam.org; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:Sender:References:Subject:Cc:To:From; bh=g8q5gPoVU1cYnyhJrGbuvrezm384dTHQv61eCer/Ndc=; b=FFP6/um/NuWHMTYICAAMGQSOylXYL3ZfLl/lvRfje4RU28cEk6/DjOT0wE4+w3n+neiIDOyHYXC2XQn74WZQtKESD2TaPuuqk8p+kdTAs26toLAl7O7Fb5JeRzIaZRj3GS59fj9kj2/0VL4a+Qv+cOCdDQkkWAOS/azcvT4TLFA=; Original-Received: from nat-office1-of1par.ip.rtblw.com ([80.70.208.129] helo=ubik.of1par.int.rtblw.com) by alawa.chezwam.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Qb7dV-0006Do-4v; Mon, 27 Jun 2011 10:57:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=ubik.of1par.int.rtblw.com) by ubik.of1par.int.rtblw.com with esmtp (Exim 4.72) (envelope-from ) id 1Qb7dU-0000yW-Mr; Mon, 27 Jun 2011 10:57:40 +0200 In-Reply-To: <87oc1l7zbp.fsf@gmx.de> (Michael Albinus's message of "Sun, 26 Jun 2011 10:48:42 +0200") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-ClamAV-Status: clean X-CW-Spam-Score: -11.0 X-Mailman-Approved-At: Mon, 27 Jun 2011 12:32:13 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 27 Jun 2011 12:33:03 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:47538 Archived-At: Michael Albinus writes: Hi, > I wouldn't like to add such a radical buffer kill. Asynchronous > processes on remote hosts would loose their output buffer, when they > have finished. Debugging of Tramp problems would be harder. I do totally agree with you about the debugging purposes. So why not setting up a variable such as: (defcustom tramp-kill-process-buffer-on-exit nil=20 "Kill remote shell buffer process if connection with remote host is lost." :group 'tramp :type 'boolean) Setting by default this variable to `nil' doesn't affect current tramp behavior. Then one can chose how tramp should handle process ending by changing `tramp-kill-process-buffer-on-exit'. And add in `tramp-maybe-open-connection': ;; Kill buffer when process died. (when tramp-kill-process-buffer-on-exit (set-process-sentinel p (lambda (proc change) (when (eq (process-status proc) 'exit) (kill-buffer (process-buffer proc))) > > On GNU Linux systems, it might be possible to catch D-Bus signals for > resuming the system after hibernate or suspend. Could you, please, eval > the following lines, and see whether Tramp behaves better? > > (require 'dbus) > (dbus-register-signal > :system "org.freedesktop.UPower" "/org/freedesktop/UPower" > "org.freedesktop.UPower" "Resuming" 'tramp-cleanup-all-connections) > > If this works for you (it does for me), I would add a custom option for > enabling this behaviour. This works fine but on in one use case on power resuming. If for some reason the connection with a remote host is lost, the dbus solution acts more like a workaround, not like a global issue solving. Cheers, --=20 S=C3=A9bastien Gross