Doom-emacs: Inactive TRAMP sessions hangs emacs

[Kitchi]

If I leave a tramp session inactive for some length of time (~ 20 or 30 mins), emacs basically becomes unresponsive. Holding down C-g doesn't help either. I'm not entirely sure if this is unique to doom-emacs, but tramp didn't bring down emacs in my vanilla config. I do not have a private doom config setup, since I only started using doom a couple of days ago.

What did you expect to happen?
...
Emacs stays responsive even if tramp times out

What actually happened?
...
No response from emacs, had to kill the process with kill, since it wouldn't respond to closing the window via GUI either.

Steps to reproduce:

1. SSH into a remote server via tramp
2. Leave the buffer open until tramp goes inactive
3. emacs then becomes unresponsive.

System information:

Package cl is deprecated

((emacs

  (version . "28.0.50")

  (features . "XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD PDUMPER LCMS2 GMP")

  (build . "Feb 20, 2020")

  (buildopts "--build=x86_64-linux-gnu --prefix=/usr '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib --program-suffix=-snapshot --with-modules=yes --with-x=yes --with-x-toolkit=gtk3 --with-xwidgets=yes 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs-snapshot-W1CepB/emacs-snapshot-99749=. -fstack-protector-strong -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'")

  (windowsys . batch)

  (daemonp . server-running))

 (doom

  (version . "2.0.9")

  (build . "HEAD -> develop, origin/develop, origin/HEAD e3d7b2662 2020-02-18 00:20:35 -0500")

  (dir . "~/.doom.d/"))

 (system

  (type . gnu/linux)

  (config . "x86_64-pc-linux-gnu")

  (shell . "/bin/bash")

  (uname . "Linux 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64")

  (path "~/src/anaconda3/bin" "~/src/anaconda3/condabin" "~/.local/bin" "~/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "/usr/local/games" "/snap/bin" "~/stuff/data/casa/casa-pipeline-release-5.6.1-8.el7/bin" "~/bin" "/usr/lib/x86_64-linux-gnu/emacs/28.0.50/x86_64-linux-gnu"))

 (config

  (envfile . envvar-file)

  (elc-files . 1)

  (modules :completion company ivy :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold multiple-cursors rotate-text snippets :emacs dired electric ibuffer vc :checkers syntax :tools (eval +overlay) (lookup +docsets) magit :lang data emacs-lisp markdown (org +dragndrop +present) sh :config (default +bindings +smartparens))

  (packages . "<(void-function sp-point-in-string)>")

  (elpa "n/a")

  (unpin . "<(void-function sp-point-in-string)>")))

[Strech]

I have similar behavior, but with basic workflow. I open 2 workspaces and during C-x C-... it hangs, and only kill help.

Not sure how to provide more valuable input. Should I try run it in debug mode?

[Kitchi]

This problem seems to have disappeared for the moment - I modified my config and ran doom sync yesterday, and since then it hasn't been an issue. I'll update here if that changes.

[Kitchi]

False positive - the problem has resurfaced, where an inactive SSH session completely hangs emacs and has to be killed. Likewise - any assistance on what information would be useful is great.

[hlissner]

I'm told that the common cause for this is that the remote host has an unconventional prompt (which tramp can't parse), and setting your prompt to $ when $TERM == "dumb" in your shell config (on the remote machine(s)) should fix it. e.g.

if [[ "$TERM" == "dumb" ]]; then
  unset zle_bracketed_paste
  unset zle
  PS1='$ '
  return
fi

Could you give that a try?

[Kitchi]

@hlissner Thanks for the suggestion! I'm going to cautiously say it's worked, but I haven't tested it out too much to confirm. The prompt on the remote was the standard CentOS bash prompt, but maybe tramp had some trouble with it.

[Kitchi]

EDIT : Had it wrong in the old version of this comment.

@hlissner - This doesn't seem to be the fix, so please let me know if there are any other logs etc that will help you debug this!

Thanks for all your help!

[eribertt]

Just recently i got myself connecting to remote server doom tramp mode and experienced this issue as well. After some gap of inactivity it took a good 5 minutes or so for emacs to become responsive again. I dont know if running a script in the remote shell sort of a loop ping to keep the activity will work. In my dot ssh/config file i keep ServerAliveInterval value to 5 but doesnt seem to improve things.

[edwin-koh]

I have the same problem. If the server goes down, the entire emacs will stop. Even C-g doen's work.

I got following message buffer.

Quit
QuitError during redisplay: (eval (doom-modeline-segment--buffer-info)) signaled (quit "")
Error during redisplay: (eval (doom-modeline-segment--buffer-info)) signaled (quit "")
Quit
Process has died
Tramp: Opening connection for [email protected] using ssh...
Tramp: Sending command ‘exec ssh -l root -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none 192.168.0.29’
Tramp: Waiting for prompts from remote shell...failed
Tramp: Opening connection for [email protected] using ssh...failed
Cleaning up the recentf list...
File /ssh:[email protected]:/xxx removed from the recentf list
File ~/xxxxx removed from the recentf list
Error during redisplay: (eval (doom-modeline-segment--buffer-info)) signaled (quit "")
Tramp: Opening connection for [email protected] using ssh...

[dapritchard]

I am having the same issue. Emacs goes into a period of high CPU activity for 5-10 minutes and then becomes responsive again. Interestingly, I had two Emacs sessions connected to the same server, and both hung at the same time, and then both became responsive again at about the same time.

Using sudo pkill -SIGUSR2 emacs in the terminal doesn't seem to help, but when Emacs did come back I had the following backtrace. (This backtrace seems very typical when it does happen.)

Debugger entered--entering a function:
* tramp-signal-hook-function(quit nil)
  tramp-get-connection-property(#<process *tramp/ssh test.stat.novisci.internal*> "check-remote-echo" nil)
  tramp-check-for-regexp(#<process *tramp/ssh test.stat.novisci.internal*> "\\(^\\|\0\\)[^#$\n]*///e1491450520ad247f723a2baea851150...")
  tramp-wait-for-regexp(#<process *tramp/ssh test.stat.novisci.internal*> nil "\\(^\\|\0\\)[^#$\n]*///e1491450520ad247f723a2baea851150...")
  tramp-wait-for-output(#<process *tramp/ssh test.stat.novisci.internal*>)
  tramp-send-command((tramp-file-name "ssh" nil nil "test.stat.novisci.internal" nil "/share/projects/P0025/users/dpritchard/R/analy-est..." nil) "/usr/bin/test -e /share/projects/P0025/users/dprit...")
  tramp-send-command-and-check((tramp-file-name "ssh" nil nil "test.stat.novisci.internal" nil "/share/projects/P0025/users/dpritchard/R/analy-est..." nil) "/usr/bin/test -e /share/projects/P0025/users/dprit...")
  tramp-sh-handle-file-exists-p("/ssh:test.stat.novisci.internal:/share/projects/P0...")
  apply(tramp-sh-handle-file-exists-p "/ssh:test.stat.novisci.internal:/share/projects/P0...")
  tramp-sh-file-name-handler(file-exists-p "/ssh:test.stat.novisci.internal:/share/projects/P0...")
  apply(tramp-sh-file-name-handler file-exists-p "/ssh:test.stat.novisci.internal:/share/projects/P0...")
  tramp-file-name-handler(file-exists-p "/ssh:test.stat.novisci.internal:/share/projects/P0...")
  file-exists-p("/ssh:test.stat.novisci.internal:/share/projects/P0...")
  doom-modeline-update-buffer-file-state-icon()
  doom-modeline-segment--buffer-info()
  eval((doom-modeline-segment--buffer-info))
  redisplay_internal\ \(C\ function\)()

[hlissner]

Judging from these error logs, it seems the issue is originating from the doom-modeline plugin. I'd recommend reporting it upstream (I do not maintain that package).

In the meantime, try the :ui (modeline +light) modeline. It doesn't use doom-modeline.

[mathrick]

This also reliably breaks TRAMP on sudo: paths. It hangs with Tramp: Opening connection for root@megumi using sudo... forever. I can get out of it using C-g, but it renders sudo: unusable. Switching to light modeline fixes it.

[mathrick]

Actually, now that I went back to doom-modeline to verify things for the bug report, it works even after I re-enabled it and re-ran doom sync. I'm confused, but it seems to work fine now.

[verbal007]

I'm told that the common cause for this is that the remote host has an unconventional prompt (which tramp can't parse), and setting your prompt to $ when $TERM == "dumb" in your shell config (on the remote machine(s)) should fix it. e.g.

Your suggestion worked for me, HOWEVER I think my issue is different than what @Kitchi is experiencing, as I was trying to establish an _initial_ connection which was hanging and eventually timing out with a tramp password error.