std.posix: Added error message 'ProcessNotFound' for reading and writing in a Linux process

[chrboesch]

This error occurs if the process to be read from or written to no longer exists.

Fixes #19875

[chrboesch]

I can't complete this PR due to the complexity of the dependencies. Since I can't test on MacOS or Windows and the error message only says "test-fmt transitive error", I don't know how to fix this.

[alexrp]

It means you have code formatting violations; run zig build fmt.

[ehaas]

These should be doc comments (/// instead of //)

[linusg]

This handles ENOENT aka errno 2 aka error.FileNotFound, the linked issue is about ESRCH (errno 3).

[chrboesch]

Because Linux returns the ENOENT error for a process (aka file) that no longer exists when trying to read or write to it.
The ESRCH error occurs when you try to kill a process or process group that no longer exists.

[linusg]

Then it would be good to note that in the original issue so the author knows they're mistaken or can clarify the situation in which ESRCH gets returned :)

[chrboesch]

#19875 (comment)

[alexrp]

Actually, I'm not so confident in this change on second thought, given this: giampaolo/psutil@22651a6#diff-d969f5377d3dc82ba7501f4c9f6d6510e1240df2debdca7c726a9ff37fde7af7R1340-R1349

I think this behavior needs to be verified manually.

[chrboesch]

I think this behavior needs to be verified manually.

What do you mean exactly?

[alexrp]

As in, write a test program that does:

• open("/proc/pid/maps", ...) for a non-existent pid, and then checks what the returned open() error is.
• open("/proc/pid/maps", ...) for a running pid, then kill(pid, SIGKILL) and read(fd, &buf, 1024), and then checks what the returned read() error is.

[chrboesch]

I did this manually on two different Linux systems (Arch, Gentoo) to check which error I get. A test program is difficult because the PIDs change every time and in principle two programs have to start, which tell each other the PID they currently have. Would be feasible. Only why? I think the result will be the same as with my tests. And if that changes in Linux (in a future kernel), we have to make adjustments anyway.

[alexrp]

The commit I linked above claims that the returned error for read() on a dead process is ESRCH rather than ENOENT. I don't know which is correct, which is why I suggested verifying it manually with a test program. But if you've already done that, then there's no issue.

[chrboesch]

I also assumed that an ESRCH error would occur, but I received ENOENT. I then analyzed the kernel source code in 'fs/proc/fd.c', and in the function 'proc_readfd_common', only ENOENT is used. No idea what the Python folks are doing, but ESRCH is definitely not returned on an x64 system.
Here the source from 'linux_6.6.47:

static int proc_readfd_common(struct file *file, struct dir_context *ctx,
			      instantiate_t instantiate)
{
	struct task_struct *p = get_proc_task(file_inode(file));
	unsigned int fd;

	if (!p)
		return -ENOENT;

...

[mlugg]

Please don't post LLM-generated content on the issue tracker. A glorified text prediction engine does not provide any useful perspective or information.

[chrboesch]

No prob, I deleted it.