Fzf: Fatal Error: Failed to open /dev/tty

Created on 11 Dec 2015  Â·  23Comments  Â·  Source: junegunn/fzf

I just installed this on my server via ssh and got this error when I pressed CTRL+R:

$(__fzf_history__)panic: Failed to open /dev/tty

goroutine 8 [running]:
github.com/junegunn/fzf/src/curses.Init(0xc82000e180, 0x470100)
    /go/src/github.com/junegunn/fzf/src/curses/curses.go:261 +0xc9
github.com/junegunn/fzf/src.NewTerminal.func1()
    /go/src/github.com/junegunn/fzf/src/terminal.go:233 +0x36
github.com/junegunn/fzf/src.(*Terminal).Loop(0xc820058b60)
    /go/src/github.com/junegunn/fzf/src/terminal.go:744 +0x368
created by github.com/junegunn/fzf/src.Run
    /go/src/github.com/junegunn/fzf/src/core.go:202 +0xe84

goroutine 1 [semacquire]:
sync.runtime_Syncsemacquire(0xc820018350)
    /go1.5/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820018340)
    /go1.5/src/sync/cond.go:62 +0x9b
github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc82000e520, 0xc82004bef0)
    /go/src/github.com/junegunn/fzf/src/util/eventbox.go:32 +0xb5
github.com/junegunn/fzf/src.Run(0xc82000c2c0)
    /go/src/github.com/junegunn/fzf/src/core.go:275 +0xfb2
main.main()
    /go/src/github.com/junegunn/fzf/src/fzf/main.go:6 +0x25

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /go1.5/src/runtime/asm_amd64.s:1696 +0x1

goroutine 5 [syscall]:
os/signal.loop()
    /go1.5/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
    /go1.5/src/os/signal/signal_unix.go:28 +0x37

goroutine 11 [runnable]:
github.com/junegunn/fzf/src.(*Terminal).Loop.func2(0xc82001c540, 0xc820058b60)
    /go/src/github.com/junegunn/fzf/src/terminal.go:736
created by github.com/junegunn/fzf/src.(*Terminal).Loop
    /go/src/github.com/junegunn/fzf/src/terminal.go:741 +0x330

goroutine 7 [semacquire]:
sync.runtime_Syncsemacquire(0xc820018390)
    /go1.5/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820018380)
    /go1.5/src/sync/cond.go:62 +0x9b
github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc82000e580, 0xc820028f60)
    /go/src/github.com/junegunn/fzf/src/util/eventbox.go:32 +0xb5
github.com/junegunn/fzf/src.(*Matcher).Loop(0xc8200127e0)
    /go/src/github.com/junegunn/fzf/src/matcher.go:67 +0x93
created by github.com/junegunn/fzf/src.Run
    /go/src/github.com/junegunn/fzf/src/core.go:197 +0xe18

goroutine 9 [runnable, locked to thread]:
runtime.gopark(0x622d40, 0xc82001c478, 0x5dd050, 0x9, 0x16, 0x3)
    /go1.5/src/runtime/proc.go:185 +0x163
runtime.goparkunlock(0xc82001c478, 0x5dd050, 0x9, 0x16, 0x3)
    /go1.5/src/runtime/proc.go:191 +0x54
runtime.chansend(0x55ee20, 0xc82001c420, 0xc82002970c, 0xc820029601, 0x453369, 0x2)
    /go1.5/src/runtime/chan.go:197 +0x499
runtime.chansend1(0x55ee20, 0xc82001c420, 0xc82002970c)
    /go1.5/src/runtime/chan.go:92 +0x43
runtime.ensureSigM.func1()
    /go1.5/src/runtime/signal1_unix.go:238 +0x2a9
runtime.goexit()
    /go1.5/src/runtime/asm_amd64.s:1696 +0x1

goroutine 10 [chan receive]:
github.com/junegunn/fzf/src.(*Terminal).Loop.func1(0xc82001c3c0, 0xc820058b60)
    /go/src/github.com/junegunn/fzf/src/terminal.go:730 +0x36
created by github.com/junegunn/fzf/src.(*Terminal).Loop
    /go/src/github.com/junegunn/fzf/src/terminal.go:732 +0x1e2

Most helpful comment

For the users running into this after Ubuntu update, it's a kernel regression. See https://github.com/junegunn/fzf/issues/1486

All 23 comments

Can you tell me more about your server?

It's a Classic VPS from OVH. I'm running Ubuntu 15.10, with a uname of

Linux starbeamrainbowlabs.com 2.6.32-042stab111.12 #1 SMP Thu Sep 17
11:38:20 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux

I connect to it via SSH - I do have access to it's console, but that
uses the web interface and it's kinda ugly - I much prefer SSH. I can't
change my kernel, interestingly enough - OVH update it automagically for
me. Other than that, I have full root access and can do what ever I want.

I have a single virtual core running at 2GHz I think, 1GB or RAM, and
10GB of hard drive space.

On 11/12/15 07:38, Junegunn Choi wrote:

Can you tell me more about your server?

—
Reply to this email directly or view it on GitHub
https://github.com/junegunn/fzf/issues/447#issuecomment-163866119.

  • Do you have no problem opening other TUI programs, like vim, top, etc?
  • Do you use ssh command to connect? Then try using -t option which forces pseudo-terminal allocation.
  • Nope, I don't have problems using vim and top.
  • Yes, I do use ssh to connect on Linux. I also use PuTTY when I'm at
    university, but I am not in a position to test that. I've tested it
    with -t, but that doesn't help.

Here's an extract from htop: http://i.imgur.com/5eaR1xB.png

Edit: Image disappeared for some reason.

Interesting.

  • Is ruby available on the server? If so, can you check the output of ruby -rio/console -e'p IO::console'?
  • And cat /proc/tty/drivers

Here's an extract from my terminal:

sbrl@starbeamrainbowlabs:~$ ruby -rio/console -e'p IO::console'
nil
sbrl@starbeamrainbowlabs:~$ cat /proc/tty/drivers
cat: /proc/tty/drivers: No such file or directory
sbrl@starbeamrainbowlabs:~$ ls /proc/tty
ls: cannot access /proc/tty: No such file or directory
sbrl@starbeamrainbowlabs:~$ ls /proc
1      15882  22384  26331  359  5781     fairsched    stat
10     15998  22385  26332  363  5803     fairsched2   swaps
11     16899  22387  26687  370  5817     filesystems  sys
12     19670  22392  27588  4    6        fs           sysrq-trigger
12289  2      22393  27590  405  6671     kmsg         sysvipc
12439  20258  22394  27808  423  7        loadavg      uptime
13995  20333  22395  27918  427  77       locks        user_beancounters
14391  22200  22399  28192  442  8        meminfo      version
14399  22376  22402  28240  443  9        modules      vmstat
14552  22379  23661  28241  461  cgroups  mounts       vz
14684  22380  23662  28260  463  cmdline  net
14685  22381  23663  2948   5    cpuinfo  partitions
15880  22383  24712  3      556  devices  self

What is the output of tty command?

(We can find the file name of the terminal with the command. However, we _can't_ use the output instead of hard-coded /dev/tty since fzf is usually used as a filter where stdin is not the terminal)

Right, I _think_ I understand. Here's the output of the tty command:

sbrl@starbeamrainbowlabs:~$ tty
/dev/pts/0

Wish I could help, but I can't simulate such environment neither on linux nor on osx where /dev/tty is unavailable but tty command succeeds.

When I connect to a remote host via ssh with -T option which disables pseudo-terminal allocation, /dev/tty becomes unavailable and fzf fails with the same error you reported, but tty command as well fails and vim or top do not work smoothly as expected.

> echo $TERM
dumb
> cat /dev/tty
cat: /dev/tty: No such device or address
> tty
not a tty
> fzf
panic: Failed to open /dev/tty
...
> top
TERM environment variable not set.
> TERM=xterm top
top: failed tty get
...

Is there anything I can do to help?

Hmm, can you try connecting to the server with -tt option, e.g. ssh -tt ..., or maybe even -ttt though I'm not sure if it makes any difference, but some people suggested using -ttt, so.

Excerpt from the man page:

-t      Force pseudo-terminal allocation.  This can be used to execute arbitrary screen-based programs on a remote machine, which can be
        very useful, e.g. when implementing menu services.  Multiple -t options force tty allocation, even if ssh has no local tty.

@junegunn Nope, no luck with -ttt. I still get /dev/pty/0. Here's the output from the above commands again whilst logged in with -ttt:

sbrl@starbeamrainbowlabs:/tmp/fzf$ ruby -rio/console -e'p IO::console'
nil
sbrl@starbeamrainbowlabs:/tmp/fzf$  cat /proc/tty/drivers
cat: /proc/tty/drivers: No such file or directory
sbrl@starbeamrainbowlabs:/tmp/fzf$ cat /proc/tty/
cat: /proc/tty/: No such file or directory
sbrl@starbeamrainbowlabs:/tmp/fzf$ ls /proc
1      13995  15882  23661  27492  27502  27564  31948  405  5     9           filesystems  mounts      sysrq-trigger
10     14391  15998  23662  27494  27503  27565  31949  423  556   cgroups     fs           net         sysvipc
11     14399  16899  23663  27495  27505  27777  31950  427  6     cmdline     kmsg         partitions  uptime
12     14552  19670  24712  27496  27508  27778  359    442  6671  cpuinfo     loadavg      self        user_beancounters
12289  14684  2      27264  27499  27510  27810  363    443  7     devices     locks        stat        version
12439  14685  20258  27489  27500  27511  2948   370    461  77    fairsched   meminfo      swaps       vmstat
13537  15880  20333  27490  27501  27512  3      4      463  8     fairsched2  modules      sys         vz
sbrl@starbeamrainbowlabs:/tmp/fzf$ tty
/dev/pts/0

I could perhaps create you a limited temporary account on my server if you are unable to replicate a suitable testing environment.

A bit more information about my server: It's virtualized using OpenVZ, and I'm using the latest RHEL kernel to my knowledge.

I've just tried PuTTY, but I still get pty/0.

Another update:

I've taken a look at the code, and think the problem lies in src/curses.go on line 259 (I haven't learnt go though). The code makes the assumption that /dev/tty is available, when in reality it isn't always. Perhaps a better approach would be this:

  • Run the tty command. If it succeeds, then try opening the path that it returns.
  • If it fails, try opening /dev/tty.
  • If that fails, panic.

That would catch every possible scenario.

I still get /dev/pty/0

The output itself is not invalid. The absence of /dev/tty and other terminal programs still working nevertheless is the situation I've never experienced and fzf is not the only program that assumes the existence of /dev/tty. e.g. https://gitlab.com/procps-ng/procps/blob/master/ps/global.c#L136

I briefly mentioned about the approach you suggested in the previous comment. STDIN to fzf is usually not terminal (e.g. history | fzf) so tty command will fail and will not give the file name we can use (history | tty fails).

I could perhaps create you a limited temporary account on my server if you are unable to replicate a suitable testing environment.

Probably this is the only way I can take a look at the problem, though I'm not sure if I'll be able to find the solution. It would be much better if you could create a Dockerfile that can be used to create a virtual machine with the same environment locally.

Docker file? How do I do that? I haven't encountered docker before.

I haven't been able to find a way not to rely on /dev/tty for getting key presses when stdin is redirected. /dev/tty is a standard linux device name and the absence of it usually means non-interactive terminal. Any help is appreciated.

@junegunn If I open /dev/tty on my laptop with cat, anything I type into it get's echoed back as expected. If I do the same on the server, I get a permission denied.

If, however, I run the tty command, on the server it returns /dev/pty/0, and on my laptop it returns /dev/pty/4. Opening them both with cat on their respective machines works like a charm.

Would it be possible to try opening /dev/tty, and if that fails run the tty command to determine the terminal to try next?

No, like I said above, tty command is not the answer. We normally use fzf with stdin redirection, e.g. history | fzf. And what do we get when we do history | tty? not a tty error.

By the way, I have never seen /dev/tty missing on interactive shell on Linux servers. RHEL, Centos, Ubuntu, Nixos, Arch linux, NixOS, never had the problem. Have you tried contacting OVH about it?

@junegunn Ah I see. That _is_ a problem. I have just tried contacting OVH and pointed them towards this bug - hopefully I'll get a response in a day or two.

Here's the message I sent:

Hello,
I have recently been taking a look at some software that I wanted to install on my VPS, but the software in question is unable to open /dev/tty, and the developer has advised me to contact you.

Here's a link to the issue with the software in question: https://github.com/junegunn/fzf/issues/447

Did you get any response?

@junegunn Thanks for reminding me to update this issue! I think I did, yeah, but it boiled down to the virtualisation tool they used for the 2014 range of VPSes. I'm renting a different (much better!) server now, so it should work. I'll check it out :D

For the users running into this after Ubuntu update, it's a kernel regression. See https://github.com/junegunn/fzf/issues/1486

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  Â·  3Comments

fenuks picture fenuks  Â·  3Comments

jberglinds picture jberglinds  Â·  3Comments

sandric picture sandric  Â·  3Comments

erusev picture erusev  Â·  3Comments