-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
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
We just need to plumb the 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 |
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. |
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
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
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
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
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
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
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
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
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
Fixes #10925 PiperOrigin-RevId: 679682913
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
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
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. |
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
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
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 immediatelyI tried with podman as well and got the exact same results.
Steps to reproduce
runsc version
docker version (if using docker)
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
The text was updated successfully, but these errors were encountered: