pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.\" Copyright (c) 2019 by Michael Kerrisk <mtk.manpages@gmail.com>
|
|
|
|
.\"
|
|
|
|
.\" %%%LICENSE_START(VERBATIM)
|
|
|
|
.\" Permission is granted to make and distribute verbatim copies of this
|
|
|
|
.\" manual provided the copyright notice and this permission notice are
|
|
|
|
.\" preserved on all copies.
|
|
|
|
.\"
|
|
|
|
.\" Permission is granted to copy and distribute modified versions of this
|
|
|
|
.\" manual under the conditions for verbatim copying, provided that the
|
|
|
|
.\" entire resulting derived work is distributed under the terms of a
|
|
|
|
.\" permission notice identical to this one.
|
|
|
|
.\"
|
|
|
|
.\" Since the Linux kernel and libraries are constantly changing, this
|
|
|
|
.\" manual page may be incorrect or out-of-date. The author(s) assume no
|
|
|
|
.\" responsibility for errors or omissions, or for damages resulting from
|
|
|
|
.\" the use of the information contained herein. The author(s) may not
|
|
|
|
.\" have taken the same level of care in the production of this manual,
|
|
|
|
.\" which is licensed free of charge, as they might when working
|
|
|
|
.\" professionally.
|
|
|
|
.\"
|
|
|
|
.\" Formatted or processed versions of this manual, if unaccompanied by
|
|
|
|
.\" the source, must acknowledge the copyright and authors of this work.
|
|
|
|
.\" %%%LICENSE_END
|
|
|
|
.\"
|
getent.1, ldd.1, locale.1, localedef.1, memusage.1, memusagestat.1, mtrace.1, _exit.2, _syscall.2, accept.2, access.2, acct.2, add_key.2, adjtimex.2, alloc_hugepages.2, arch_prctl.2, bdflush.2, bind.2, bpf.2, brk.2, cacheflush.2, capget.2, chdir.2, chmod.2, chown.2, chroot.2, clock_getres.2, clock_nanosleep.2, clone.2, close.2, close_range.2, connect.2, copy_file_range.2, create_module.2, delete_module.2, dup.2, epoll_create.2, epoll_ctl.2, epoll_wait.2, eventfd.2, execve.2, execveat.2, fanotify_init.2, fanotify_mark.2, fcntl.2, flock.2, fork.2, fsync.2, futex.2, get_kernel_syms.2, get_mempolicy.2, get_robust_list.2, getcpu.2, getdents.2, getdomainname.2, getgid.2, getgroups.2, gethostname.2, getitimer.2, getpagesize.2, getpeername.2, getpid.2, getpriority.2, getrandom.2, getresuid.2, getrlimit.2, getrusage.2, getsid.2, getsockname.2, getsockopt.2, gettid.2, gettimeofday.2, getuid.2, getunwind.2, getxattr.2, idle.2, init_module.2, inotify_add_watch.2, inotify_rm_watch.2, io_cancel.2, io_destroy.2, io_getevents.2, io_setup.2, io_submit.2, ioctl.2, ioctl_console.2, ioctl_fat.2, ioctl_ficlonerange.2, ioctl_fideduperange.2, ioctl_fslabel.2, ioctl_getfsmap.2, ioctl_ns.2, ioctl_tty.2, ioctl_userfaultfd.2, ioperm.2, iopl.2, ipc.2, kcmp.2, kexec_load.2, keyctl.2, kill.2, link.2, listen.2, listxattr.2, llseek.2, lookup_dcookie.2, lseek.2, madvise.2, mbind.2, membarrier.2, memfd_create.2, migrate_pages.2, mincore.2, mkdir.2, mknod.2, mlock.2, mmap.2, mmap2.2, modify_ldt.2, mount.2, move_pages.2, mprotect.2, mq_getsetattr.2, mremap.2, msgctl.2, msgget.2, msgop.2, msync.2, nanosleep.2, nfsservctl.2, nice.2, open.2, open_by_handle_at.2, openat2.2, pause.2, pciconfig_read.2, perf_event_open.2, perfmonctl.2, personality.2, pidfd_getfd.2, pidfd_open.2, pidfd_send_signal.2, pipe.2, pivot_root.2, pkey_alloc.2, poll.2, posix_fadvise.2, prctl.2, pread.2, process_vm_readv.2, ptrace.2, query_module.2, quotactl.2, read.2, readahead.2, readdir.2, readlink.2, readv.2, reboot.2, recv.2, remap_file_pages.2, removexattr.2, rename.2, request_key.2, restart_syscall.2, rmdir.2, rt_sigqueueinfo.2, s390_guarded_storage.2, s390_pci_mmio_write.2, s390_runtime_instr.2, s390_sthyi.2, sched_get_priority_max.2, sched_rr_get_interval.2, sched_setaffinity.2, sched_setattr.2, sched_setparam.2, sched_setscheduler.2, sched_yield.2, seccomp.2, select.2, select_tut.2, semctl.2, semget.2, semop.2, send.2, sendfile.2, set_thread_area.2, seteuid.2, setfsgid.2, setfsuid.2, setgid.2, setpgid.2, setresuid.2, setreuid.2, setsid.2, setuid.2, setup.2, setxattr.2, sgetmask.2, shmctl.2, shmget.2, shmop.2, shutdown.2, sigaction.2, sigaltstack.2, signal.2, signalfd.2, sigpending.2, sigprocmask.2, sigreturn.2, sigsuspend.2, sigwaitinfo.2, socket.2, socketcall.2, socketpair.2, splice.2, spu_create.2, spu_run.2, stat.2, statfs.2, statx.2, stime.2, subpage_prot.2, swapon.2, symlink.2, sync.2, sync_file_range.2, syscall.2, syscalls.2, sysctl.2, sysfs.2, sysinfo.2, syslog.2, time.2, timer_create.2, timer_delete.2, timer_getoverrun.2, timer_settime.2, timerfd_create.2, times.2, tkill.2, truncate.2, umask.2, umount.2, uname.2, unimplemented.2, unlink.2, unshare.2, uselib.2, userfaultfd.2, ustat.2, utime.2, utimensat.2, vfork.2, vhangup.2, vm86.2, vmsplice.2, wait.2, wait4.2, write.2, CPU_SET.3, __ppc_get_timebase.3, __ppc_set_ppr_med.3, __ppc_yield.3, __setfpucw.3, a64l.3, abort.3, abs.3, acos.3, acosh.3, addseverity.3, adjtime.3, aio_cancel.3, aio_error.3, aio_fsync.3, aio_read.3, aio_return.3, aio_suspend.3, aio_write.3, alloca.3, argz_add.3, asin.3, asinh.3, asprintf.3, assert.3, assert_perror.3, atan.3, atan2.3, atanh.3, atexit.3, atof.3, atoi.3, backtrace.3, basename.3, bcmp.3, bcopy.3, bindresvport.3, bsd_signal.3, bsearch.3, bstring.3, btowc.3, byteorder.3, bzero.3, cabs.3, cacos.3, cacosh.3, canonicalize_file_name.3, carg.3, casin.3, casinh.3, catan.3, catanh.3, catgets.3, catopen.3, cbrt.3, ccos.3, ccosh.3, ceil.3, cexp.3, cexp2.3, cfree.3, cimag.3, circleq.3, clearenv.3, clock.3, clock_getcpuclockid.3, clog.3, clog10.3, clog2.3, closedir.3, cmsg.3, confstr.3, conj.3, copysign.3, cos.3, cosh.3, cpow.3, cproj.3, creal.3, crypt.3, csin.3, csinh.3, csqrt.3, ctan.3, ctanh.3, ctermid.3, ctime.3, daemon.3, des_crypt.3, difftime.3, dirfd.3, div.3, dl_iterate_phdr.3, dladdr.3, dlerror.3, dlinfo.3, dlopen.3, dlsym.3, drand48.3, drand48_r.3, duplocale.3, dysize.3, ecvt.3, ecvt_r.3, encrypt.3, endian.3, envz_add.3, erf.3, erfc.3, err.3, errno.3, error.3, ether_aton.3, euidaccess.3, exec.3, exit.3, exp.3, exp10.3, exp2.3, expm1.3, fabs.3, fclose.3, fcloseall.3, fdim.3, fenv.3, ferror.3, fexecve.3, fflush.3, ffs.3, fgetc.3, fgetgrent.3, fgetpwent.3, fgetwc.3, fgetws.3, fileno.3, finite.3, flockfile.3, floor.3, fma.3, fmax.3, fmemopen.3, fmin.3, fmod.3, fmtmsg.3, fnmatch.3, fopen.3, fopencookie.3, fpathconf.3, fpclassify.3, fpurge.3, fputwc.3, fputws.3, fread.3, frexp.3, fseek.3, fseeko.3, ftime.3, ftok.3, fts.3, ftw.3, futimes.3, fwide.3, gamma.3, gcvt.3, get_nprocs_conf.3, get_phys_pages.3, getaddrinfo.3, getaddrinfo_a.3, getauxval.3, getcontext.3, getcwd.3, getdate.3, getdirentries.3, getdtablesize.3, getentropy.3, getenv.3, getfsent.3, getgrent.3, getgrent_r.3, getgrnam.3, getgrouplist.3, gethostbyname.3, gethostid.3, getifaddrs.3, getipnodebyname.3, getline.3, getloadavg.3, getlogin.3, getmntent.3, getnameinfo.3, getnetent.3, getnetent_r.3, getopt.3, getpass.3, getprotoent.3, getprotoent_r.3, getpt.3, getpw.3, getpwent.3, getpwent_r.3, getpwnam.3, getrpcent.3, getrpcent_r.3, getrpcport.3, gets.3, getservent.3, getservent_r.3, getspnam.3, getsubopt.3, getttyent.3, getumask.3, getusershell.3, getutent.3, getutmp.3, getw.3, getwchar.3, glob.3, gnu_get_libc_version.3, grantpt.3, group_member.3, gsignal.3, hsearch.3, hypot.3, iconv.3, iconv_close.3, iconv_open.3, if_nameindex.3, if_nametoindex.3, ilogb.3, index.3, inet.3, inet_net_pton.3, inet_ntop.3, inet_pton.3, initgroups.3, insque.3, isalpha.3, isatty.3, isfdtype.3, isgreater.3, iswalnum.3, iswalpha.3, iswblank.3, iswcntrl.3, iswctype.3, iswdigit.3, iswgraph.3, iswlower.3, iswprint.3, iswpunct.3, iswspace.3, iswupper.3, iswxdigit.3, j0.3, key_setsecret.3, killpg.3, ldexp.3, lgamma.3, lio_listio.3, list.3, localeconv.3, lockf.3, log.3, log10.3, log1p.3, log2.3, logb.3, login.3, lrint.3, lround.3, lsearch.3, lseek64.3, makecontext.3, makedev.3, mallinfo.3, malloc.3, malloc_get_state.3, malloc_hook.3, malloc_info.3, malloc_stats.3, malloc_trim.3, malloc_usable_size.3, mallopt.3, matherr.3, mblen.3, mbrlen.3, mbrtowc.3, mbsinit.3, mbsnrtowcs.3, mbsrtowcs.3, mbstowcs.3, mbtowc.3, mcheck.3, memccpy.3, memchr.3, memcmp.3, memcpy.3, memfrob.3, memmem.3, memmove.3, mempcpy.3, memset.3, mkdtemp.3, mkfifo.3, mkstemp.3, mktemp.3, modf.3, mpool.3, mq_close.3, mq_getattr.3, mq_notify.3, mq_open.3, mq_receive.3, mq_send.3, mq_unlink.3, mtrace.3, nan.3, newlocale.3, nextafter.3, nextup.3, nl_langinfo.3, ntp_gettime.3, on_exit.3, open_memstream.3, opendir.3, openpty.3, perror.3, popen.3, posix_fallocate.3, posix_madvise.3, posix_memalign.3, posix_openpt.3, posix_spawn.3, pow.3, pow10.3, printf.3, profil.3, psignal.3, pthread_attr_init.3, pthread_attr_setaffinity_np.3, pthread_attr_setdetachstate.3, pthread_attr_setguardsize.3, pthread_attr_setinheritsched.3, pthread_attr_setschedparam.3, pthread_attr_setschedpolicy.3, pthread_attr_setscope.3, pthread_attr_setsigmask_np.3, pthread_attr_setstack.3, pthread_attr_setstackaddr.3, pthread_attr_setstacksize.3, pthread_cancel.3, pthread_cleanup_push.3, pthread_cleanup_push_defer_np.3, pthread_create.3, pthread_detach.3, pthread_equal.3, pthread_exit.3, pthread_getattr_default_np.3, pthread_getattr_np.3, pthread_getcpuclockid.3, pthread_join.3, pthread_kill.3, pthread_kill_other_threads_np.3, pthread_mutex_consistent.3, pthread_mutexattr_getpshared.3, pthread_mutexattr_setrobust.3, pthread_rwlockattr_setkind_np.3, pthread_self.3, pthread_setaffinity_np.3, pthread_setcancelstate.3, pthread_setconcurrency.3, pthread_setname_np.3, pthread_setschedparam.3, pthread_setschedprio.3, pthread_sigmask.3, pthread_sigqueue.3, pthread_spin_init.3, pthread_spin_lock.3, pthread_testcancel.3, pthread_tryjoin_np.3, pthread_yield.3, ptsname.3, putenv.3, putgrent.3, putpwent.3, puts.3, putwchar.3, qecvt.3, qsort.3, raise.3, rand.3, random.3, random_r.3, rcmd.3, re_comp.3, readdir.3, readdir_r.3, realpath.3, regex.3, remainder.3, remove.3, remquo.3, resolver.3, rewinddir.3, rexec.3, rint.3, round.3, rpc.3, rpmatch.3, rtime.3, rtnetlink.3, scalb.3, scalbln.3, scandir.3, scanf.3, sched_getcpu.3, seekdir.3, sem_close.3, sem_destroy.3, sem_getvalue.3, sem_init.3, sem_open.3, sem_post.3, sem_unlink.3, sem_wait.3, setaliasent.3, setbuf.3, setenv.3, setjmp.3, setlocale.3, setlogmask.3, setnetgrent.3, shm_open.3, siginterrupt.3, signbit.3, significand.3, sigpause.3, sigqueue.3, sigset.3, sigsetops.3, sigvec.3, sigwait.3, sin.3, sincos.3, sinh.3, sleep.3, slist.3, sockatmark.3, sqrt.3, stailq.3, statvfs.3, stdarg.3, stdio.3, stdio_ext.3, stpcpy.3, stpncpy.3, strcasecmp.3, strcat.3, strchr.3, strcmp.3, strcoll.3, strcpy.3, strdup.3, strerror.3, strfmon.3, strfromd.3, strfry.3, strftime.3, string.3, strlen.3, strnlen.3, strpbrk.3, strptime.3, strsep.3, strsignal.3, strspn.3, strstr.3, strtod.3, strtoimax.3, strtok.3, strtol.3, strtoul.3, strverscmp.3, strxfrm.3, swab.3, sysconf.3, syslog.3, system.3, sysv_signal.3, tailq.3, tan.3, tanh.3, tcgetpgrp.3, tcgetsid.3, telldir.3, tempnam.3, termios.3, tgamma.3, timegm.3, timeradd.3, tmpfile.3, tmpnam.3, toascii.3, toupper.3, towctrans.3, towlower.3, towupper.3, trunc.3, tsearch.3, ttyname.3, ttyslot.3, tzset.3, ualarm.3, ulimit.3, undocumented.3, ungetwc.3, unlocked_stdio.3, unlockpt.3, updwtmp.3, uselocale.3, usleep.3, wcpcpy.3, wcpncpy.3, wcrtomb.3, wcscasecmp.3, wcscat.3, wcschr.3, wcscmp.3, wcscpy.3, wcscspn.3, wcsdup.3, wcslen.3, wcsncasecmp.3, wcsncat.3, wcsncmp.3, wcsncpy.3, wcsnlen.3, wcsnrtombs.3, wcspbrk.3, wcsrchr.3, wcsrtombs.3, wcsspn.3, wcsstr.3, wcstoimax.3, wcstok.3, wcstombs.3, wcswidth.3, wctob.3, wctomb.3, wctrans.3, wctype.3, wcwidth.3, wmemchr.3, wmemcmp.3, wmemcpy.3, wmemmove.3, wmemset.3, wordexp.3, wprintf.3, xcrypt.3, xdr.3, y0.3, cciss.4, console_codes.4, dsp56k.4, hpsa.4, initrd.4, loop.4, lp.4, msr.4, random.4, rtc.4, smartpqi.4, veth.4, wavelan.4, acct.5, core.5, elf.5, hosts.5, locale.5, proc.5, resolv.conf.5, rpc.5, slabinfo.5, sysfs.5, tmpfs.5, utmp.5, address_families.7, aio.7, attributes.7, bootparam.7, capabilities.7, cgroups.7, complex.7, ddp.7, environ.7, epoll.7, fanotify.7, feature_test_macros.7, hier.7, inode.7, inotify.7, ip.7, ipv6.7, keyrings.7, locale.7, man-pages.7, man.7, math_error.7, mount_namespaces.7, namespaces.7, netdevice.7, netlink.7, numa.7, packet.7, pkeys.7, pthreads.7, queue.7, raw.7, rtnetlink.7, sched.7, session-keyring.7, shm_overview.7, sigevent.7, signal-safety.7, signal.7, sock_diag.7, socket.7, spufs.7, symlink.7, system_data_types.7, tcp.7, time_namespaces.7, udp.7, udplite.7, unicode.7, unix.7, uri.7, user_namespaces.7, vdso.7, vsock.7, x25.7, iconvconfig.8, ld.so.8, ldconfig.8, sln.8, tzselect.8: tstamp
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-03-21 23:15:34 +00:00
|
|
|
.TH PIDFD_OPEN 2 2021-03-22 "Linux" "Linux Programmer's Manual"
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.SH NAME
|
|
|
|
pidfd_open \- obtain a file descriptor that refers to a process
|
|
|
|
.SH SYNOPSIS
|
|
|
|
.nf
|
2021-05-10 17:55:39 +00:00
|
|
|
.BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
|
|
|
|
.B #include <unistd.h>
|
|
|
|
.PP
|
|
|
|
.BI "int syscall(SYS_pidfd_open, pid_t " pid ", unsigned int " flags );
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.fi
|
Various pages: Normalize SYNOPSIS notes about nonexistent glibc wrappers
To easily distinguish documentation about glibc wrappers from
documentation about kernel syscalls, let's have a normalized
'Note' in the SYNOPSIS, and a further explanation in the page body
(NOTES in most of them), as already happened in many (but not all)
of the manual pages for syscalls without a wrapper. Furthermore,
let's normalize the messages, following membarrier.2 (because it's
already quite extended), so that it's easy to use grep to find
those pages.
To find these pages, we used:
$ grep -rn wrapper man? | sort -V
and
$ grep -rni support.*glibc | sort -V
delete_module.2, init_module.2: glibc 2.23 is no longer
maintained, so we changed the notes about wrappers, to say that
there are no glibc wrappers for these system calls; see NOTES.
We didn't fix some obsolete pages such as create_module.2.
Signed-off-by: Ganimedes Colomar <gacoan.linux@gmail.com>
Cowritten-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2020-12-30 15:20:25 +00:00
|
|
|
.PP
|
|
|
|
.IR Note :
|
2021-05-10 17:55:39 +00:00
|
|
|
glibc provides no wrapper for
|
|
|
|
.BR pidfd_open (),
|
|
|
|
necessitating the use of
|
|
|
|
.BR syscall (2).
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.SH DESCRIPTION
|
|
|
|
The
|
|
|
|
.BR pidfd_open ()
|
2019-09-23 19:35:13 +00:00
|
|
|
system call creates a file descriptor that refers to
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
the process whose PID is specified in
|
|
|
|
.IR pid .
|
|
|
|
The file descriptor is returned as the function result;
|
|
|
|
the close-on-exec flag is set on the file descriptor.
|
|
|
|
.PP
|
|
|
|
The
|
|
|
|
.I flags
|
|
|
|
argument is reserved for future use;
|
|
|
|
currently, this argument must be specified as 0.
|
|
|
|
.SH RETURN VALUE
|
|
|
|
On success,
|
|
|
|
.BR pidfd_open ()
|
2020-04-08 08:28:45 +00:00
|
|
|
returns a file descriptor (a nonnegative integer).
|
2019-09-23 19:35:13 +00:00
|
|
|
On error, \-1 is returned and
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.I errno
|
2021-01-07 06:50:50 +00:00
|
|
|
is set to indicate the error.
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.SH ERRORS
|
|
|
|
.TP
|
|
|
|
.B EINVAL
|
|
|
|
.I flags
|
|
|
|
is not 0.
|
|
|
|
.TP
|
|
|
|
.B EINVAL
|
|
|
|
.I pid
|
|
|
|
is not valid.
|
|
|
|
.TP
|
2019-09-23 20:10:38 +00:00
|
|
|
.B EMFILE
|
|
|
|
The per-process limit on the number of open file descriptors has been reached
|
|
|
|
(see the description of
|
|
|
|
.BR RLIMIT_NOFILE
|
|
|
|
in
|
|
|
|
.BR getrlimit (2)).
|
|
|
|
.TP
|
|
|
|
.B ENFILE
|
|
|
|
The system-wide limit on the total number of open files has been reached.
|
|
|
|
.TP
|
|
|
|
.B ENODEV
|
|
|
|
The anonymous inode filesystem is not available in this kernel.
|
|
|
|
.TP
|
|
|
|
.B ENOMEM
|
|
|
|
Insufficient kernel memory was available.
|
|
|
|
.TP
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.B ESRCH
|
|
|
|
The process specified by
|
|
|
|
.I pid
|
|
|
|
does not exist.
|
|
|
|
.SH VERSIONS
|
|
|
|
.BR pidfd_open ()
|
|
|
|
first appeared in Linux 5.3.
|
|
|
|
.SH CONFORMING TO
|
|
|
|
.BR pidfd_open ()
|
|
|
|
is Linux specific.
|
|
|
|
.SH NOTES
|
2019-09-25 13:23:18 +00:00
|
|
|
The following code sequence can be used to obtain a file descriptor
|
|
|
|
for the child of
|
|
|
|
.BR fork (2):
|
|
|
|
.PP
|
|
|
|
.in +4n
|
|
|
|
.EX
|
|
|
|
pid = fork();
|
|
|
|
if (pid > 0) { /* If parent */
|
|
|
|
pidfd = pidfd_open(pid, 0);
|
|
|
|
...
|
|
|
|
}
|
|
|
|
.EE
|
|
|
|
.in
|
|
|
|
.PP
|
2019-09-25 13:59:12 +00:00
|
|
|
Even if the child has already terminated by the time of the
|
2019-09-25 13:23:18 +00:00
|
|
|
.BR pidfd_open ()
|
2019-09-25 13:59:12 +00:00
|
|
|
call, its PID will not have been recycled and the returned
|
|
|
|
file descriptor will refer to the resulting zombie process.
|
|
|
|
Note, however, that this is guaranteed only if the following
|
|
|
|
conditions hold true:
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu 2
|
2019-09-25 13:59:12 +00:00
|
|
|
the disposition of
|
|
|
|
.BR SIGCHLD
|
|
|
|
has not been explicitly set to
|
|
|
|
.BR SIG_IGN
|
|
|
|
(see
|
|
|
|
.BR sigaction (2));
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu
|
2019-09-25 14:16:58 +00:00
|
|
|
the
|
2019-10-30 09:23:10 +00:00
|
|
|
.BR SA_NOCLDWAIT
|
2019-09-25 14:16:58 +00:00
|
|
|
flag was not specified while establishing a handler for
|
|
|
|
.BR SIGCHLD
|
|
|
|
or while setting the disposition of that signal to
|
|
|
|
.BR SIG_DFL
|
|
|
|
(see
|
|
|
|
.BR sigaction (2));
|
2019-09-25 13:59:12 +00:00
|
|
|
and
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu
|
2019-09-25 13:59:12 +00:00
|
|
|
the zombie process was not reaped elsewhere in the program
|
|
|
|
(e.g., either by an asynchronously executed signal handler or by
|
|
|
|
.BR wait (2)
|
|
|
|
or similar in another thread).
|
|
|
|
.PP
|
2019-09-25 14:03:12 +00:00
|
|
|
If any of these conditions does not hold,
|
2019-10-12 19:12:34 +00:00
|
|
|
then the child process (along with a PID file descriptor that refers to it)
|
|
|
|
should instead be created using
|
2019-09-25 13:59:12 +00:00
|
|
|
.BR clone (2)
|
|
|
|
with the
|
2019-09-25 14:01:32 +00:00
|
|
|
.BR CLONE_PIDFD
|
2019-09-25 13:59:12 +00:00
|
|
|
flag.
|
2019-10-12 19:14:58 +00:00
|
|
|
.\"
|
|
|
|
.SS Use cases for PID file descriptors
|
2019-10-12 19:18:40 +00:00
|
|
|
A PID file descriptor returned by
|
|
|
|
.BR pidfd_open ()
|
2020-02-23 00:39:56 +00:00
|
|
|
(or by
|
2019-10-12 19:18:40 +00:00
|
|
|
.BR clone (2)
|
|
|
|
with the
|
|
|
|
.BR CLONE_PID
|
|
|
|
flag) can be used for the following purposes:
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu 2
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
The
|
|
|
|
.BR pidfd_send_signal (2)
|
|
|
|
system call can be used to send a signal to the process referred to by
|
|
|
|
a PID file descriptor.
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
A PID file descriptor can be monitored using
|
|
|
|
.BR poll (2),
|
|
|
|
.BR select (2),
|
|
|
|
and
|
|
|
|
.BR epoll (7).
|
|
|
|
When the process that it refers to terminates,
|
2019-09-23 19:27:01 +00:00
|
|
|
these interfaces indicate the file descriptor as readable.
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
Note, however, that in the current implementation,
|
2019-09-23 19:41:50 +00:00
|
|
|
nothing can be read from the file descriptor
|
|
|
|
.RB ( read (2)
|
|
|
|
on the file descriptor fails with the error
|
|
|
|
.BR EINVAL ).
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu
|
2019-10-12 20:40:09 +00:00
|
|
|
If the PID file descriptor refers to a child of the calling process,
|
|
|
|
then it can be waited on using
|
|
|
|
.BR waitid (2).
|
2020-06-15 13:02:05 +00:00
|
|
|
.IP \(bu
|
2020-03-31 12:05:24 +00:00
|
|
|
The
|
|
|
|
.BR pidfd_getfd (2)
|
|
|
|
system call can be used to obtain a duplicate of a file descriptor
|
|
|
|
of another process referred to by a PID file descriptor.
|
2020-06-15 13:04:16 +00:00
|
|
|
.IP \(bu
|
|
|
|
A PID file descriptor can be used as the argument of
|
|
|
|
.BR setns (2)
|
|
|
|
in order to move into one or more of the same namespaces as the process
|
|
|
|
referred to by the file descriptor.
|
2021-02-02 08:17:27 +00:00
|
|
|
.IP \(bu
|
|
|
|
A PID file descriptor can be used as the argument of
|
|
|
|
.BR process_madvise (2)
|
|
|
|
in order to provide advice on the memory usage patterns of the process
|
|
|
|
referred to by the file descriptor.
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.PP
|
2019-09-23 08:00:19 +00:00
|
|
|
The
|
|
|
|
.BR pidfd_open ()
|
2019-10-12 19:05:04 +00:00
|
|
|
system call is the preferred way of obtaining a PID file descriptor
|
|
|
|
for an already existing process.
|
2019-09-23 08:00:19 +00:00
|
|
|
The alternative is to obtain a file descriptor by opening a
|
|
|
|
.I /proc/[pid]
|
|
|
|
directory.
|
|
|
|
However, the latter technique is possible only if the
|
|
|
|
.BR proc (5)
|
2019-10-13 19:04:32 +00:00
|
|
|
filesystem is mounted;
|
2019-09-23 08:00:19 +00:00
|
|
|
furthermore, the file descriptor obtained in this way is
|
|
|
|
.I not
|
2019-10-12 20:40:09 +00:00
|
|
|
pollable and can't be waited on with
|
|
|
|
.BR waitid (2).
|
2020-05-21 08:00:37 +00:00
|
|
|
.SH EXAMPLES
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
The program below opens a PID file descriptor for the
|
|
|
|
process whose PID is specified as its command-line argument.
|
2019-09-23 20:07:21 +00:00
|
|
|
It then uses
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.BR poll (2)
|
2019-09-23 20:07:21 +00:00
|
|
|
to monitor the file descriptor for process exit, as indicated by an
|
|
|
|
.BR EPOLLIN
|
|
|
|
event.
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.\"
|
|
|
|
.SS Program source
|
|
|
|
\&
|
2020-11-16 09:52:29 +00:00
|
|
|
.EX
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
#define _GNU_SOURCE
|
2019-09-23 19:13:11 +00:00
|
|
|
#include <sys/types.h>
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
#include <sys/syscall.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <poll.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#ifndef __NR_pidfd_open
|
2019-09-23 19:43:07 +00:00
|
|
|
#define __NR_pidfd_open 434 /* System call # on most architectures */
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
#endif
|
|
|
|
|
2019-09-23 09:43:13 +00:00
|
|
|
static int
|
|
|
|
pidfd_open(pid_t pid, unsigned int flags)
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
{
|
|
|
|
return syscall(__NR_pidfd_open, pid, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
main(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
struct pollfd pollfd;
|
|
|
|
int pidfd, ready;
|
|
|
|
|
|
|
|
if (argc != 2) {
|
|
|
|
fprintf(stderr, "Usage: %s <pid>\en", argv[0]);
|
|
|
|
exit(EXIT_SUCCESS);
|
|
|
|
}
|
|
|
|
|
|
|
|
pidfd = pidfd_open(atoi(argv[1]), 0);
|
|
|
|
if (pidfd == \-1) {
|
|
|
|
perror("pidfd_open");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
pollfd.fd = pidfd;
|
|
|
|
pollfd.events = POLLIN;
|
|
|
|
|
|
|
|
ready = poll(&pollfd, 1, \-1);
|
|
|
|
if (ready == \-1) {
|
|
|
|
perror("poll");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
eventfd.2, mprotect.2, pidfd_open.2, spu_run.2, timer_create.2, bswap.3, dl_iterate_phdr.3, endian.3, pthread_attr_init.3, pthread_getattr_np.3, vcs.4, rtld-audit.7: In printf(): s/0x%/%#/ except when followed by X instead of x
Use printf()'s '#' flag character to prepend the string "0x".
However, when the number is printed in uppercase, and the prefix
is in lowercase, the string "0x" needs to be manually written.
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2020-09-11 20:53:51 +00:00
|
|
|
printf("Events (%#x): POLLIN is %sset\en", pollfd.revents,
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
(pollfd.revents & POLLIN) ? "" : "not ");
|
|
|
|
|
2020-07-17 07:13:31 +00:00
|
|
|
close(pidfd);
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
exit(EXIT_SUCCESS);
|
|
|
|
}
|
2020-11-16 09:52:29 +00:00
|
|
|
.EE
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.SH SEE ALSO
|
|
|
|
.BR clone (2),
|
|
|
|
.BR kill (2),
|
2020-03-31 12:05:24 +00:00
|
|
|
.BR pidfd_getfd (2),
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.BR pidfd_send_signal (2),
|
|
|
|
.BR poll (2),
|
2021-02-02 08:17:27 +00:00
|
|
|
.BR process_madvise (2),
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.BR select (2),
|
2020-06-15 13:04:16 +00:00
|
|
|
.BR setns (2),
|
2019-10-12 20:40:09 +00:00
|
|
|
.BR waitid (2),
|
pidfd_open.2: New page documenting pidfd_open(2)
Notes from a conversation on linux-man@ with Christian Brauner:
[[
> [*} By the way, going forward, can we call these things
> "process FDs", rather than "PID FDs"? The API names are what
> they are, an that's okay, but these just as we have socket
> FDs that refer to sockets, directory FDs that refer to
> directories, and timer FDs that refer to timers, and so on,
> these are FDs that refer to *processes*, not "process IDs".
> It's a little thing, but I think the naming better, and
> it's what I propose to use in the manual pages.
The naming was another debate and we ended with this compromise.
I would just clarify that a pidfd is a process file descriptor. I
wouldn't make too much of a deal of hiding the shortcut "pidfd".
People are already using it out there in the wild and it's never
proven a good idea to go against accepted practice.
]]
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2019-09-22 21:05:48 +00:00
|
|
|
.BR epoll (7)
|