7

I've been using tramp to edit remote files for a few years now, but suddenly it stopped working yesterday. I haven't changed anything relevant that I can think of. For testing, I tried opening a file on localhost with \C-x C-f /ssh:localhost:/home/terdon/test. That bring up the Waiting for prompts from remote shell... message and times out after about a minute with:

Timeout reached, see buffer '*tramp/ssh localhost*' for details

The *tramp/ssh localhost* is shown in the buffers menu but disappears as soon as I try to switch to it.

Details

  • I am running GNU emacs 25.3.1 on Arch Linux.
  • I have updated my system and the elpa packages I have installed.
  • To rule out problems with the remote prompt, I have replaced my ~/.bashrc and ~/.profile with:

    $ cat ~/.bashrc
    PS1='$ '
    $ cat ~/.profile
    PS1='$ '
    

    Yes, my default shell is bash and no, I don't have a ~/.bash_profile.

  • I have set up passwordless ssh to all the servers that I've tried and which used to work. Including localhost (ssh localhost works fine with no password).

  • My .emacs file has (the full file can be found here: https://pastebin.com/QGgPE3SS):

    (setq tramp-default-method "sshx")
    (setq tramp-verbose 10)
    
  • The contents of the *debug tramp/ssh localhost* buffer are here: https://pastebin.com/F6r6d5cN.

  • I read Tramp: Waiting for prompts from remote shell... Sending command `exec ssh -e none bin' and added these lines to my ~/.ssh/config file:

    Host *
      ControlPath ~/.ssh/master-%r@%h:%p
      ControlMaster auto
      ControlPersist = no 
    

    However, despite that, as you can see in the output in the previous bullet point, I still get command-line line 0: Missing ControlPersist argument line. Is that an issue?

  • Running the ssh command from tramp's log maually works fine:

    $ ssh -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none localhost
    Last login: Tue Apr 24 13:58:15 2018 from ::1
    $ 
    
  • Trying the same thing after loading emacs with emacs -Q gives the same problem, so it isn't something to do with my ~/.emacs.

  • I created a new user with default settings and tried as that user and it worked! So while emacs -Q doesn't solve the issue, running as a new user does! What could cause that?

What else can I check? How can I get my tramp back again?

terdon
  • 745
  • 6
  • 21
  • You have set `tramp-verbose` to 10, so there is a Tramp debug buffer. Pls show it. – Michael Albinus Apr 24 '18 at 14:45
  • @MichaelAlbinus I link to it in my penultimate bullet point: https://pastebin.com/F6r6d5cN (sorry, I guess it got lost in the noise, I was trying to give as much detail as I could). – terdon Apr 24 '18 at 14:49
  • According to the traces, Tramp sends the command "`exec ssh -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none localhost`". Afterwards, it waits 1 minute for output, but nothing happens. Could you try the command from a shell, and see what happens? – Michael Albinus Apr 24 '18 at 16:36
  • @MichaelAlbinus that works immediately. I log into `localhost` after ~1sec or less. – terdon Apr 24 '18 at 16:38
  • Strange. Have you tried to use Tramp with a clean Emacs, after calling `emacs -Q` ? – Michael Albinus Apr 24 '18 at 18:09
  • @MichaelAlbinus argh, should have thought of that, thanks. Anyway, I just tried it and got the same issue. Weird. Even weirder, however, I tried creating a new user and then opened a file as that user and it worked! What can cause that? `emacs -Q` still failing and yet a new user with a default configuration working? – terdon Apr 24 '18 at 18:24
  • @MichaelAlbinus thank you very much for your help. I finally tracked the problem down: it was a malformed line in `~/.inputrc`. Removing that line fixed the problem. Now why the local `.inputrc` would affect opening a remote shell (when connecting to an actual remote machine, not `localhost`, of course), I have no idea. – terdon Apr 24 '18 at 20:41

2 Answers2

3

This is an issue mentioned in the Emacs Wiki:

If you have Control-j mapped in your ~/.inputrc ... it can cause tramp to never finish recognizing the shell prompt.

For me, the problem went away when I conditionally defined C-j binding only for non-dumb terminals:

$if term=dumb
# skip
$else
Control-j: foo
$endif
Davor Cubranic
  • 700
  • 4
  • 9
2

It turns out the problem was a malformed ~/.inputrc file. I had been playing around with it while trying to answer a question over at Unix & Linux and had left this line:

Control-J: "$(date)"

Removing that line fixed my problem with tramp. I don't understand why the local ~/.inputrc would affect my remote shell (I also faced this problem when connecting to actual remote hosts, not only localhost), but apparently it did.

terdon
  • 745
  • 6
  • 21