Thanks for working on this, Benjamin.

How are you testing this? AFAICT it's not currently possible to run a pidfd-supporting kernel in any of the hosted CI services. (Except maybe via User-Mode Linux, which I've seriously considered, but it's non-trivial.) Has anyone checked whether we have a buildbot running a new enough kernel? Having some kind of CI coverage seems important.

I'm running a 5.3 kernel locally. The lack of CI is indeed troubling, but I expect it to be a temporary situation on the order of months. The next Ubunu LTS 20.04 will presumably support pidfds. I'm hoping CI will be available before 3.9 is released.

I checked AMD64 Fedora Rawhide 3.x buildbot: it runs Linux 5.4 (release 5.4.0-0.rc5.git0.1.fc32.x86_64).

Sweet, sounds like we're all set then.

Perfect, thanks ;-)

Just a heads up: In Fedora, I am getting:

======================================================================
FAIL: test_pidfd_open (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.9.0a1/Lib/test/test_posix.py", line 1479, in test_pidfd_open
    self.assertEqual(cm.exception.errno, errno.EINVAL)
AssertionError: 1 != 22

----------------------------------------------------------------------

When building Python 3.9.0a1. I'm still investigating as I can only get the problem in local chroot, but not in the remote build system.

EDIT: The remote build system has an older kernel.

https://bugzilla.redhat.com/show_bug.cgi?id=1774417#c2

Sounds like you're using some kind of buggy sandbox that's returning EPERM for unrecognized syscalls: https://bugs.python.org/issue38692#msg356235