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, localedef.1, accept.2, arch_prctl.2, clock_getres.2, clock_nanosleep.2, connect.2, dup.2, epoll_create.2, epoll_ctl.2, epoll_wait.2, execve.2, getitimer.2, getsockopt.2, gettid.2, inotify_add_watch.2, inotify_init.2, io_submit.2, ioctl.2, lseek.2, madvise.2, mlock.2, mmap.2, mprotect.2, msgctl.2, msgop.2, open_by_handle_at.2, openat2.2, pidfd_open.2, poll.2, prctl.2, quotactl.2, s390_sthyi.2, select.2, select_tut.2, semctl.2, semget.2, semop.2, setns.2, shmctl.2, shmget.2, shmop.2, sigaction.2, stat.2, statx.2, syscalls.2, timer_create.2, timerfd_create.2, unshare.2, wait.2, CPU_SET.3, aio_init.3, atoi.3, des_crypt.3, dirfd.3, fmemopen.3, fopencookie.3, ftok.3, fts.3, getaddrinfo.3, getifaddrs.3, getrpcent.3, gsignal.3, lio_listio.3, nl_langinfo.3, posix_memalign.3, posix_openpt.3, posix_spawn.3, scanf.3, sem_init.3, sem_post.3, shm_open.3, strcmp.3, strftime.3, st.4, elf.5, group.5, proc.5, services.5, aio.7, cgroups.7, feature_test_macros.7, keyrings.7, man-pages.7, namespaces.7, path_resolution.7, sigevent.7, signal.7, socket.7, sysvipc.7, time.7, udp.7: tstamp
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2020-04-11 20:07:24 +00:00
|
|
|
.TH PIDFD_OPEN 2 2020-04-11 "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
|
2019-09-23 19:13:11 +00:00
|
|
|
.B #include <sys/types.h>
|
|
|
|
.PP
|
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
|
|
|
.BI "int pidfd_open(pid_t " pid ", unsigned int " flags );
|
|
|
|
.fi
|
|
|
|
.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
|
|
|
|
is set to indicate the cause of the error.
|
|
|
|
.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
|
|
|
|
Currently, there is no glibc wrapper for this system call; call it using
|
|
|
|
.BR syscall (2).
|
|
|
|
.PP
|
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:
|
|
|
|
.IP * 3
|
|
|
|
the disposition of
|
|
|
|
.BR SIGCHLD
|
|
|
|
has not been explicitly set to
|
|
|
|
.BR SIG_IGN
|
|
|
|
(see
|
|
|
|
.BR sigaction (2));
|
2019-09-25 14:16:58 +00:00
|
|
|
.IP *
|
|
|
|
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
|
|
|
|
.IP *
|
|
|
|
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-09-25 13:23:18 +00:00
|
|
|
.PP
|
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:
|
|
|
|
.IP * 3
|
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.
|
2019-10-12 19:18:40 +00:00
|
|
|
.IP *
|
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 ).
|
2019-10-12 20:40:09 +00:00
|
|
|
.IP *
|
|
|
|
If the PID file descriptor refers to a child of the calling process,
|
|
|
|
then it can be waited on using
|
|
|
|
.BR waitid (2).
|
2020-03-31 12:05:24 +00:00
|
|
|
.IP *
|
|
|
|
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.
|
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).
|
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 EXAMPLE
|
|
|
|
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
|
|
|
|
\&
|
|
|
|
.nf
|
|
|
|
#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);
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("Events (0x%x): POLLIN is %sset\en", pollfd.revents,
|
|
|
|
(pollfd.revents & POLLIN) ? "" : "not ");
|
|
|
|
|
|
|
|
exit(EXIT_SUCCESS);
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.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),
|
|
|
|
.BR select (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)
|