Skip to content
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

std.posix: Added 'error.ProcessNotFound' where necessary #23268

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

chrboesch
Copy link
Contributor

If you attempt to read (or other operations) from a process previously opened via openat, but it has since terminated, the Linux kernel throws the error ESRCH - No such process. This is now represented by error.ProcessNotFound.

fixes #19875

@alexrp
Copy link
Member

alexrp commented Mar 16, 2025

I'm not really clear on the conditions under which we get ENOENT vs ESRCH. Can you clarify?

@rootbeer
Copy link
Contributor

(Let me preface this comment by saying, do whatever Alex says, and feel free to ignore me.)

I think this PR correctly maps the errno code on read/write when operating on a /proc/<pid>/ path, where ESRCH means that the process that was previously backing a proc entry is no longer present. For example Linux's fs/proc/base.c:proc_pid_cmdline_read returns ESRCH in this case.

Also since POSIX defines ESRCH as "No such process" this mapping seems relatively stable (even if other kinds of handles like sockets or FUSE or whatnot besides /proc handles might return ESRCH.)

From what I can tell (in the proc/base.c code), ENOENT is used in the proc code when the race lookup is more filesystemy (i.e., during an open or readdir callback, not so much read/write). E.g., in fs/proc/base.c:proc_map_files_readdir. So Zig's conversion to ProcessNotFound may make sense when the open handle points into /proc, but ENOENT could happen in regular directories, too. It is not clear that ProcessNotFound would always be the right conversion.

Doing this mapping at read/write where you can't know what kind of handle is being used (e.g., if its a socket, a FUSE handle, or an open proc handle, etc), seems likely to cause confusion to me. (Also I don't see evidence of Linux using ENOENT in read/write paths in the main proc handlers, but I wouldn't be at all surprised if there are some out there somewhere that do ....)

I think Zig's posix layer can get away with specializing some errno from some syscalls. But I think it'll be hard to do that correctly from syscalls like read or write that can be used on so many different kinds of handles and where the semantics of a specific errno may be specific to the kind of handle.

My suggestion on this PR is that the ESRCH to ProcessNotFound works, but the exisiting mapping of ENOENT (which generally means "file or directory not found") to ProcessNotFound is not something Zig should be doing on syscalls like read and write.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ESRCH is not handled by file io operations
3 participants