Is ghostty leaking filedescriptors to the shell? #4196

stschulte · 2024-12-31T15:05:54Z

stschulte
Dec 31, 2024

It looks like commands executed in ghostty inherit filedescriptors coming originally from ghostty. I am not sure this is by design, if these needs to be inherited by the shell (zsh in my case) but should be close by zsh, or if this is a problem in ghostty itself. Here is what I observe:

I noticed lvm commands complain about filedescriptors leaked from the parent process (so lvm sees fds that have been opened by the parent and the parent did not use O_CLOEXEC or closed the filehandle explicitly before execing the lvm process.

Freshly started ghostty with zsh as my shell:

% lvdisplay -C
File descriptor 3 (/home/dummy/.cache/ghostty/sentry/b0dde05d-49d1-460d-4efe-b5056b8a2cad.run.lock) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 19 (anon_inode:[eventfd]) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 20 (anon_inode:[eventfd]) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 21 (anon_inode:[eventfd]) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 22 (anon_inode:[eventfd]) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 23 (anon_inode:[eventfd]) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 25 (/dev/ptmx) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 26 (anon_inode:[eventfd]) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 27 (/dev/pts/0) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
File descriptor 28 (/sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-67536.scope/surfaces/55E043BAE670.service) leaked on lvdisplay invocation. Parent PID 69880: /bin/zsh
...

This is not happening when running through gnome-terminal. When I run ls -l /proc/$$/fd from a freshly spawned terminal to see what filehandles zsh has, I get this in gnome-terminal:

lrwx------ 1 dummy dummy 64 31. Dez 15:45 0 -> /dev/pts/5
lrwx------ 1 dummy dummy 64 31. Dez 15:45 1 -> /dev/pts/5
lrwx------ 1 dummy dummy 64 31. Dez 15:45 10 -> /dev/pts/5
lrwx------ 1 dummy dummy 64 31. Dez 15:45 2 -> /dev/pts/5

and the following listing in ghostty:

lrwx------ 1 dummy dummy 64 31. Dez 15:44 0 -> /dev/pts/2
lrwx------ 1 dummy dummy 64 31. Dez 15:44 1 -> /dev/pts/2
lrwx------ 1 dummy dummy 64 31. Dez 15:44 10 -> /dev/pts/2
l-wx------ 1 dummy dummy 64 31. Dez 15:44 13 -> /dev/pts/2
lrwx------ 1 dummy dummy 64 31. Dez 15:44 19 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 2 -> /dev/pts/2
lrwx------ 1 dummy dummy 64 31. Dez 15:44 20 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 21 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 22 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 23 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 25 -> /dev/ptmx
lrwx------ 1 dummy dummy 64 31. Dez 15:44 26 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 27 -> /dev/pts/0
l--------- 1 dummy dummy 64 31. Dez 15:44 28 -> /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-67536.scope/surfaces/55E043BAE670.service
lr-x------ 1 dummy dummy 64 31. Dez 15:44 29 -> pipe:[136173]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 3 -> /home/dummy/.cache/ghostty/sentry/b0dde05d-49d1-460d-4efe-b5056b8a2cad.run.lock
l-wx------ 1 dummy dummy 64 31. Dez 15:44 30 -> pipe:[136173]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 32 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 33 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 35 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 36 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 38 -> /dev/ptmx
l--------- 1 dummy dummy 64 31. Dez 15:44 40 -> /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-67536.scope/surfaces/55E044ABD620.service
lrwx------ 1 dummy dummy 64 31. Dez 15:44 41 -> /dev/pts/4
l--------- 1 dummy dummy 64 31. Dez 15:44 42 -> /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-67536.scope/surfaces/55E044A77E90.service
lr-x------ 1 dummy dummy 64 31. Dez 15:44 43 -> pipe:[27987]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 44 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 45 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 46 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 48 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 49 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 50 -> /dev/ptmx
l-wx------ 1 dummy dummy 64 31. Dez 15:44 51 -> pipe:[27987]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 52 -> /dev/pts/3
l--------- 1 dummy dummy 64 31. Dez 15:44 53 -> /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-67536.scope/surfaces/55E044F24CA0.service
lr-x------ 1 dummy dummy 64 31. Dez 15:44 54 -> pipe:[32384]
l-wx------ 1 dummy dummy 64 31. Dez 15:44 55 -> pipe:[32384]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 58 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 59 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 60 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 62 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64 31. Dez 15:44 63 -> anon_inode:[eventfd]
l--------- 1 dummy dummy 64 31. Dez 15:44 67 -> /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-67536.scope/surfaces/55E0454BD670.service

Should these file handles all be available to the shell process?

Answered by mitchellh

Jan 24, 2025

Oof. Good find, I'm surprised this slipped through the beta program. Fixed in #5341. Note, there are still some fds being leaked but they seem GTK-related and I'm not entirely sure where they come from. I plan to look into it but the linked PR fixes the major issues.

View full answer

stschulte · 2025-01-02T14:11:17Z

stschulte
Jan 2, 2025
Author

I realized what I showed is not the minimal example. The number of open filehandles depends on the number of parallel ghostty terminals you run from within the same ghostty process. The first terminal instance let's the child inherit the following fds:

lrwx------ 1 dummy dummy 64  2. Jan 12:04 0 -> /dev/pts/0
lrwx------ 1 dummy dummy 64  2. Jan 15:09 1 -> /dev/pts/0
lrwx------ 1 dummy dummy 64  2. Jan 15:09 10 -> /dev/pts/0
l-wx------ 1 dummy dummy 64  2. Jan 15:09 13 -> /dev/pts/0
lrwx------ 1 dummy dummy 64  2. Jan 15:09 19 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64  2. Jan 15:09 2 -> /dev/pts/0
lrwx------ 1 dummy dummy 64  2. Jan 15:09 21 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64  2. Jan 15:09 22 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64  2. Jan 15:09 23 -> anon_inode:[eventfd]
lrwx------ 1 dummy dummy 64  2. Jan 15:09 26 -> anon_inode:[eventfd]
l--------- 1 dummy dummy 64  2. Jan 15:09 28 -> /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-2859.scope/surfaces/562FEE42E5F0.service
lrwx------ 1 dummy dummy 64  2. Jan 15:09 3 -> /home/dummy/.cache/ghostty/sentry/8fb76b41-987d-4735-a871-3d4adaae525b.run.lock

0 replies

notcancername · 2025-01-21T06:48:33Z

notcancername
Jan 21, 2025

I am experiencing this as well.
~~Possible cause: ziglang/zig#18887~~
Ghostty uses its own process spawning code, with the same problem.

1 reply

notcancername Jan 21, 2025

Previously, I experienced this with Mesa shader cache files, but recently, O_CLOEXEC has been added: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30988

mitchellh · 2025-01-24T06:08:59Z

mitchellh
Jan 24, 2025
Maintainer

Oof. Good find, I'm surprised this slipped through the beta program. Fixed in #5341. Note, there are still some fds being leaked but they seem GTK-related and I'm not entirely sure where they come from. I plan to look into it but the linked PR fixes the major issues.

1 reply

stschulte Jan 24, 2025
Author

Hi @mitchellh, let me know if I can help. I build from main (fd8caca) with zig build -Doptimize=ReleaseFast and I don't see any unrelated fds now (running gnome on wayland) neither in the main ghostty window nor any additionally spawned windows:

% ls -l /proc/$$/fd
total 0
lrwx------ 1 ryo ryo 64 24. Jan 10:51 0 -> /dev/pts/0
lrwx------ 1 ryo ryo 64 24. Jan 10:52 1 -> /dev/pts/0
lrwx------ 1 ryo ryo 64 24. Jan 10:52 10 -> /dev/pts/0
l-wx------ 1 ryo ryo 64 24. Jan 10:52 13 -> /dev/pts/0
lrwx------ 1 ryo ryo 64 24. Jan 10:52 2 -> /dev/pts/0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Is ghostty leaking filedescriptors to the shell? #4196

{{title}}

Replies: 3 comments 2 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

Is ghostty leaking filedescriptors to the shell? #4196

stschulte Dec 31, 2024

Replies: 3 comments · 2 replies

stschulte Jan 2, 2025 Author

notcancername Jan 21, 2025

notcancername Jan 21, 2025

mitchellh Jan 24, 2025 Maintainer

stschulte Jan 24, 2025 Author

stschulte
Dec 31, 2024

Replies: 3 comments 2 replies

stschulte
Jan 2, 2025
Author

notcancername
Jan 21, 2025

mitchellh
Jan 24, 2025
Maintainer

stschulte Jan 24, 2025
Author