unable to kill-emacs due to failure to save buffers (in connection with tramp)

unable to kill-emacs due to failure to save buffers (in connection with tramp)

[Martin Steffen]

Hi,

I have a problem that from time to time pops up, which therefore does
not sounds too critical. But when it pops up, I have not figured out a
way to deal with it, and the only solution I have is to ``shoot emacs
down'' from outside (doing a "kill -9" to make sure it goes down....)

I have not figured out what factors in. Typically it occurs when some
emacs-client starts temporarily, for instance as I have set-up emacs as
default editor for some other programs, to type in a log message or a
commit etc.

After typing in the commit message, let's say, one surely wants to quite
that client, doing

      C-x C-c (save-buffers-kill-terminal)

In that situations, not much buffers are to be saved (those of
emacs-client, not of the overall emacs). Actually if I do

      C-x s

for saving buffers myself, the message is

    No buffers need saving

.  Still, when trying the above-mentioned save-buffers-kill-terminal,
emacs (client) engages in some attempt to save stuff. That seems to be
on initiative of tramp. Messages show activities like


Opening connection for <login>@192.168.x.x using scp...
Tramp: Sending command ‘exec ssh -l <login> -e none 192.168.x.x’
Tramp: Waiting for prompts from remote shell...failed Tramp: Opening

That's some address in my home network for some external memory
(NAS). Sometimes I login there using SCP to browse the
filesystem. However, I am not always at home, and the address this not
alway accessible. That's why sometimes the attempt to login there simply
won't work. When I cut-off the wait, typing C-g (keybord quote), it
stops the attempt. However, emacs (client), having failed to do its
save-the-buffers-properly-job propery, does not quit.

If I instead of save-buffers-kill-terminal do

  kill-terminal

the same happens, the tramp kicks trying to login the non-existant
address and so again I cannot quit.

Why does emacs (client) want to login to 192.168.x.x anyway? Note, the
location (resp. files at that location are not buffers in neither the
running emacs nor the emacs-client I like just to get rid of.

I assume has to do with the content of some tramp-cashing in the file
~/.emacs.d/tramp which contains a like like

;; -*- emacs-lisp -*- <22/08/14 11:00:37 /home/msteffen/.emacs.d/tramp>
;; Tramp connection history.  Don't change this file.
;; Run `M-x tramp-cleanup-all-connections' instead.

(((tramp-file-name "scp" "<login>" nil "192.168.x.x" nil nil nil)  (****)
  nil))


The recommendation in the comment sounds promising, but doing
M-x tramp-cleanup-all-connections which I tried did not help.

I executed that commend both in the mother-emacs and the client, which
cleared up some memory. For some reason, the line above (****) remained
(even if I don't have a connection to that address open since some
time).

Not even deleting the line (****) manually from the tramp-file helps. If
I do that, it reappears.

--

So that's as much as I was able to figure out, and I have not found a
better way to kill emacs via the OS. Basically, it makes emacs(-cliean)
as editor for commit-messages or similar really painful (after I visited
some site via SCP like my NAS).

Any ideas how I can teach emacs to really forget tramp history (which
seems would solve the problem) or any other idea?

best, Martin

I use

GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.17.4) of 2021-08-07

tramp-version "2.4.5.27.2" (the version that ships with my emacs offered
by the OS)

Re: unable to kill-emacs due to failure to save buffers (in connection with tramp)

[Michael Albinus]

Martin Steffen <msteffen@ifi.uio.no> writes:

> Hi,

Hi Martin,

> .  Still, when trying the above-mentioned save-buffers-kill-terminal,
> emacs (client) engages in some attempt to save stuff. That seems to be
> on initiative of tramp. Messages show activities like
>
> Opening connection for <login>@192.168.x.x using scp...
> Tramp: Sending command ‘exec ssh -l <login> -e none 192.168.x.x’
> Tramp: Waiting for prompts from remote shell...failed Tramp: Opening
>
> That's some address in my home network for some external memory
> (NAS). Sometimes I login there using SCP to browse the
> filesystem. However, I am not always at home, and the address this not
> alway accessible. That's why sometimes the attempt to login there simply
> won't work. When I cut-off the wait, typing C-g (keybord quote), it
> stops the attempt. However, emacs (client), having failed to do its
> save-the-buffers-properly-job propery, does not quit.
>
> If I instead of save-buffers-kill-terminal do
>
>   kill-terminal
>
> the same happens, the tramp kicks trying to login the non-existant
> address and so again I cannot quit.
>
> Why does emacs (client) want to login to 192.168.x.x anyway? Note, the
> location (resp. files at that location are not buffers in neither the
> running emacs nor the emacs-client I like just to get rid of.

Hard to say what's up. There have been some changes in tramp-cleanup-*
functions, which might improve the behavior. Do you have a chance to
upgrade to Tramp 2.5.3.1 from GNU ELPA?

If this still happens, pls set tramp-verbose to 6 and
tramp-debug-to-file to t. The former variable triggers Tramp to write
debug messages, and the latter one (new in Tramp 2.5) initiates to write
these debug messages to file in parallel. Good for post-mortem analysis.

Please check the Tramp messages on file whether you see something which
tells you what's up. If you don't find something, please show the file here.

> I assume has to do with the content of some tramp-cashing in the file
> ~/.emacs.d/tramp which contains a like like
>
> ;; -*- emacs-lisp -*- <22/08/14 11:00:37 /home/msteffen/.emacs.d/tramp>
> ;; Tramp connection history.  Don't change this file.
> ;; Run `M-x tramp-cleanup-all-connections' instead.
>
> (((tramp-file-name "scp" "<login>" nil "192.168.x.x" nil nil nil)  (****)
>   nil))

No, these values are active only if a connection is active. The
existence of these values does not mean that a connection is initiated.

> best, Martin
>
> I use

Best regards, Michael.

Re: unable to kill-emacs due to failure to save buffers (in connection with tramp)

[Martin Steffen]

>>>>> "Michael" == Michael Albinus <michael.albinus@gmx.de> writes:

    Michael> Martin Steffen <msteffen@ifi.uio.no> writes:

    >> Hi,

    Michael> Hi Martin,

    >> Note, the location (resp. files at that location are not buffers
    >> in neither the running emacs nor the emacs-client I like just to
    >> get rid of.

    Michael> Hard to say what's up. There have been some changes in
    Michael> tramp-cleanup-* functions, which might improve the
    Michael> behavior. Do you have a chance to upgrade to Tramp 2.5.3.1
    Michael> from GNU ELPA?

I will try that and will see the results.

    Michael> If this still happens, pls set tramp-verbose to 6 and

[...]


    >> I assume has to do with the content of some tramp-cashing in the
    >> file ~/.emacs.d/tramp which contains a like like

    Michael> No, these values are active only if a connection is
    Michael> active. The existence of these values does not mean that a
    Michael> connection is initiated.


I see. I don't know where the ``persitent'' memory of emacs is
concerning that ``undying'' (but not active) connection. In the
meantime, I killed the emacs+client (which I was unable to leave) in the
only way I know, killing both from the outside (as mentioned).

The I started a fresh emacs, and without doing anything at all, try
immediately to quit it again with C-x C-c.

The reaction is the same as before, i.e., I cannot quit, the fresh emacs
has remembered that seem to have remembered the scp-connection from some
earlier emacs invokatioms. But indeed it does not take it from
~/.emacs/tramp, as I had deleted that file completly before starting
emacs fresh.

Grep'ping for the ``offending'' address 192.168.x.x, my current best
culprit is


 ~/.cache/org-persist/index

wich mentions it a few times. For instance is expressions like

(:variable #29# :persist-file "d9/6cedfd-05fd-4dc3-8542-ee0bb93ac4b3" :path "/scp:<login>@192.168.x.x:/var/services/homes/mobileorg/test.org" :inode 11537641 :hash "672132fcd377562aa49d8dbd0044f1c4") 


The file is pretty big, and I have not yet manually fiddled with it
(like deleting expressions plausibly causing that particular trouble),
but that's my current best suspicion.

Anyway, I will try your advice upgrading tramp and see if it helps
(manually managing the huge persist-index file in case of trouble
without actually knowing what I am doing is not a long-term solution).

thanks again, best,

Martin

Re: unable to kill-emacs due to failure to save buffers (in connection with tramp)

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Grep'ping for the ``offending'' address 192.168.x.x, my current best
> culprit is
>
>
>  ~/.cache/org-persist/index
>
> wich mentions it a few times. For instance is expressions like
>
> (:variable #29# :persist-file "d9/6cedfd-05fd-4dc3-8542-ee0bb93ac4b3" :path
> "/scp:<login>@192.168.x.x:/var/services/homes/mobileorg/test.org" :inode
> 11537641 :hash "672132fcd377562aa49d8dbd0044f1c4") 

This suggests that the problem is not in Tramp but in `org-persist` (or
in your use of it), since it seems to be configured to save the value of
some variable (not shown here) into your remote server, and org-persist
probably tries to save this variable before exiting Emacs.


        Stefan

Re: unable to kill-emacs due to failure to save buffers (in connection with tramp)

[Martin Steffen]

>>>>> "Stefan" == Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:
    >> 
    >> (:variable #29# :persist-file
    >> "d9/6cedfd-05fd-4dc3-8542-ee0bb93ac4b3" :path
    >> "/scp:<login>@192.168.x.x:/var/services/homes/mobileorg/test.org"
    >> :inode 11537641 :hash "672132fcd377562aa49d8dbd0044f1c4")

    Stefan> This suggests that the problem is not in Tramp but in
    Stefan> `org-persist` (or in your use of it), since it seems to be
    Stefan> configured to save the value of some variable (not shown
    Stefan> here) into your remote server, and org-persist probably
    Stefan> tries to save this variable before exiting Emacs.

That's a plausible analysis. I was originally pointing towards Tramp, as
the *Messages* showed things like that

> Tramp: Sending command ‘exec ssh -l <login> -e none 192.168.x.x’

i.e., since it's about ``remote'' files, it's tramp that tries to do
it, but the saving seems, as you said, be triggered by ``persist''.

I will look into that. I was so far not aware that I somehow use
org-persist (or what its purpose is). I definitely use a lot of
org-packages, and I don't load or require org-persist. The only
mentioning of "persist" in my org-adaptations is

(setq org-clock-persist t)
(org-clock-persistence-insinuate)

(though I can't remember why exactly I set that, seems also not
immediately related to tramp, more about logging).

Anyway, thanks for directing me to better also look into ``persist''.

Martin

Re: unable to kill-emacs due to failure to save buffers (in connection with tramp)

[Martin Steffen]

Concerning the problem of being ``stuck'' unable to exit emacs: Indeed,
deleting ~/.cache/org-persist/index (and for good measure additionally
doing (setq org-clock-persist nil))  got me rid of the
problem. Now I can exit emacs in a decent way and especially make use of
emacs-client as editor for commit and log message (being forced to shoot
emacs down for exiting made that impossible, the main-emacs I seldomly
quit....)

Martin


>>>>> "Martin" == Martin Steffen <msteffen@ifi.uio.no> writes:




>>>>> "Stefan" == Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> writes:
    >>> 
    >>> (:variable #29# :persist-file
    >>> "d9/6cedfd-05fd-4dc3-8542-ee0bb93ac4b3" :path
    >>> "/scp:<login>@192.168.x.x:/var/services/homes/mobileorg/test.org"
    >>> :inode 11537641 :hash "672132fcd377562aa49d8dbd0044f1c4")

    Stefan> This suggests that the problem is not in Tramp but in
    Stefan> `org-persist` (or in your use of it), since it seems to be
    Stefan> configured to save the value of some variable (not shown
    Stefan> here) into your remote server, and org-persist probably
    Stefan> tries to save this variable before exiting Emacs.

    Martin> That's a plausible analysis. I was originally pointing
    Martin> towards Tramp, as the *Messages* showed things like that

    >> Tramp: Sending command ‘exec ssh -l <login> -e none 192.168.x.x’

    Martin> i.e., since it's about ``remote'' files, it's tramp that
    Martin> tries to do it, but the saving seems, as you said, be
    Martin> triggered by ``persist''.

    Martin> I will look into that. I was so far not aware that I somehow
    Martin> use org-persist (or what its purpose is). I definitely use a
    Martin> lot of org-packages, and I don't load or require
    Martin> org-persist. The only mentioning of "persist" in my
    Martin> org-adaptations is

    Martin> (setq org-clock-persist t) (org-clock-persistence-insinuate)

    Martin> (though I can't remember why exactly I set that, seems also
    Martin> not immediately related to tramp, more about logging).

    Martin> Anyway, thanks for directing me to better also look into
    Martin> ``persist''.

    Martin> Martin