Skip to content

emacs fails with "Could not open file: /dev/tty" #10925

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chetan-reddy opened this issue Sep 19, 2024 · 4 comments · Fixed by #10968
Closed

emacs fails with "Could not open file: /dev/tty" #10925

chetan-reddy opened this issue Sep 19, 2024 · 4 comments · Fixed by #10968
Assignees
Labels
type: bug Something isn't working

Comments

@chetan-reddy
Copy link

chetan-reddy commented Sep 19, 2024

Description

When I run docker run -it --rm --network=none silex/emacs , I get a working instance of emacs.
But when I try with runsc , it fails immediately

$ docker run -it --rm --runtime=runsc --network=none silex/emacs
emacs: Could not open file: /dev/tty

I tried with podman as well and got the exact same results.

Steps to reproduce

$ docker run -it --rm --runtime=runsc --network=none silex/emacs
emacs: Could not open file: /dev/tty

runsc version

runsc version release-20240916.0
spec: 1.1.0-rc.1

docker version (if using docker)

Client:
 Version:           20.10.24+dfsg1
 API version:       1.41
 Go version:        go1.19.8
 Git commit:        297e128
 Built:             Thu May 18 08:38:34 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.24+dfsg1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.19.8
  Git commit:       5d6db84
  Built:            Thu May 18 08:38:34 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.20~ds1
  GitCommit:        1.6.20~ds1-1+b1
 runc:
  Version:          1.1.5+ds1
  GitCommit:        1.1.5+ds1-1+deb12u1
 docker-init:
  Version:          0.19.0
  GitCommit:

uname

Linux mee 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

@chetan-reddy chetan-reddy added the type: bug Something isn't working label Sep 19, 2024
@kevinGC kevinGC assigned kevinGC and unassigned kevinGC Sep 19, 2024
@nlacasse nlacasse self-assigned this Sep 19, 2024
copybara-service bot pushed a commit that referenced this issue Sep 19, 2024
We need to plumb the host.TTYFileDescription into the /dev/tty device file.

This is *not* the correct way to do it, but it does allow emacs to work.

Updates #10925

DO NOT SUBMIT

PiperOrigin-RevId: 676585154
@nlacasse
Copy link
Collaborator

We just need to plumb the host.TTYFileDescription into /dev/tty device. It currently always returns EIO from open:

https://github.com/google/gvisor/blob/master/pkg/sentry/devices/ttydev/ttydev.go#L38

I hacked together #10934 , and verified that emacs runs (shudder). I need to think more about the right way to do this. That PR is not the right way.

@chetan-reddy Can you patch #10934 and check that it works for you? I only moved the cursor around and CxCc

@chetan-reddy
Copy link
Author

chetan-reddy commented Sep 19, 2024

@nlacasse I wasn't able to compile that exact PR commit, but I was able to cherry-pick your change onto an older commit on the go branch (e9d8c6f) and can confirm that emacs now works. Thanks for the fix!

@nlacasse
Copy link
Collaborator

Awesome! I need to figure out the right way to do this, but it's good to know that this is the correct approach. I'll spend more time on this in the next week or so.

copybara-service bot pushed a commit that referenced this issue Sep 25, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Sep 27, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Sep 27, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Sep 27, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Sep 30, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Sep 30, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Sep 30, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Sep 30, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Sep 30, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 2, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 2, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 2, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 2, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 678775254
copybara-service bot pushed a commit that referenced this issue Oct 2, 2024
The /dev/tty acts as a replica for the current thread group's controlling
terminal.

In a follow-up, I will make /dev/tty work for donated host ttys.

Updates #10925

PiperOrigin-RevId: 681629892
copybara-service bot pushed a commit that referenced this issue Oct 3, 2024
Fixes #10925

PiperOrigin-RevId: 679682913
copybara-service bot pushed a commit that referenced this issue Oct 3, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Oct 3, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
@nlacasse
Copy link
Collaborator

nlacasse commented Oct 3, 2024

Hi @chetan-reddy , I think this should be fixed properly now, so you can drop the hacky patch. Please let me know if it doesn't work.

copybara-service bot pushed a commit that referenced this issue Oct 3, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 679758576
copybara-service bot pushed a commit that referenced this issue Oct 3, 2024
We used to track the foreground process group & session on the
TTYFileOperation, but these are already tracked in kernel.TTY.ThreadGroup.

So remove TTYFileOperations.fgProcessGroup and .session, and replace them with
a kernel.TTY.

This is analogous to how sentry-internal tty's already work.

Updates #10925

PiperOrigin-RevId: 681957240
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants