F_GETSIG(2const)

okay bestie, gather round 💖 you've found F_GETSIG, from the <pink>2const</pink> corner of the manual (section 2, the "these are basically little fcntl() operations" zone). This page is actually a whole squad: F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG, and F_SETSIG, and together they're all about managing signals. Iconic honestly.

---

🎀 NAME

F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG, F_SETSIG — the girlypops in charge of managing signals. 💅

📚 LIBRARY

Standard C library (libc, -lc). Yes ma'am, link it. 🫶

✨ SYNOPSIS

#include <fcntl.h>

int fcntl(int fd, F_GETOWN);
int fcntl(int fd, F_SETOWN, int arg);

and then, because some of these are ✨special✨ and need the GNU macro:

#define _GNU_SOURCE
#include <fcntl.h>

int fcntl(int fd, F_GETOWN_EX, struct f_owner_ex *arg);
int fcntl(int fd, F_SETOWN_EX, const struct f_owner_ex *arg);
int fcntl(int fd, F_GETSIG);
int fcntl(int fd, F_SETSIG, int arg);

💖 DESCRIPTION

So F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG, and F_SETSIG are all about one thing: managing I/O availability signals. Let's go one by one, no skipping, we do NOT skip. 🫡

🌸 F_GETOWN

Returns (as the function result, bestie, it's the return value) the process ID or process group ID that's currently receiving SIGIO and SIGURG signals for events on the file descriptor fd.

Here's the vibe check on the sign:

• Process IDs come back as positive values.
• Process group IDs come back as negative values.

(but see BUGS below 👀). arg is ignored, it's just there chillin'.

🦋 F_SETOWN

Sets the process ID or process group ID that will receive SIGIO and SIGURG signals for events on the file descriptor fd. The target process or process group ID goes in arg:

• A process ID = a positive value.
• A process group ID = a negative value.

Most of the time, the calling process just nominates itself as the owner — that means arg is given as getpid(2). main character behavior, honestly.

⚠️ Heads up: setting the file descriptor owner is only HALF the job. You also have to actually enable generation of signals on the file descriptor. You do that with the F_SETFL(2const) operation, setting the O_ASYNC file status flag on the file descriptor. After that, a SIGIO signal gets sent whenever input or output becomes possible on the file descriptor. And if you want a signal that isn't SIGIO, that's what the fcntl() F_SETSIG operation is for. ✨

Sending a signal to the owner process (group) you named with F_SETOWN goes through the same permission checks as the ones described for kill(2) — where the sending process is the one that employs F_SETOWN (but see BUGS below). If that permission check fails, the signal is silently discarded. Silently. Rude. 😭

📌 Note: The F_SETOWN operation records the caller's credentials at the time of the fcntl() call, and it's these saved credentials that get used for the permission checks. It's giving screenshot-at-the-time-of-posting energy.

If the file descriptor fd refers to a socket, F_SETOWN also picks the recipient of SIGURG signals delivered when out-of-band data arrives on that socket. (SIGURG is sent in any situation where select(2) would report the socket as having an "exceptional condition".)

Now for the lore drop. The following was true in Linux 2.6.x up to and including Linux 2.6.11:

If a nonzero value is given to F_SETSIG in a multithreaded process running with a threading library that supports thread groups (e.g., NPTL), then a positive value given to F_SETOWN has a different meaning: instead of being a process ID identifying a whole process, it's a thread ID identifying a specific thread within a process. Consequently, it may be necessary to pass F_SETOWN the result of gettid(2) instead of getpid(2) to get sensible results when F_SETSIG is used. (In current Linux threading implementations, a main thread's thread ID is the same as its process ID. This means that a single-threaded program can equally use gettid(2) or getpid(2) in this scenario.) Note, however, that the statements in this paragraph do not apply to the SIGURG signal generated for out-of-band data on a socket: this signal is always sent to either a process or a process group, depending on the value given to F_SETOWN.

The above behavior was accidentally dropped in Linux 2.6.12, and won't be restored. 🪦 From Linux 2.6.32 onward, use F_SETOWN_EX to target SIGIO and SIGURG signals at a particular thread. That's the upgrade, bestie.

🌈 F_GETOWN_EX

Returns the current file descriptor owner settings as defined by a previous F_SETOWN_EX operation. The info comes back in the structure pointed to by arg, which looks like this:

struct f_owner_ex {
    int   type;
    pid_t pid;
};

The type field will have one of the values F_OWNER_TID, F_OWNER_PID, or F_OWNER_PGRP. The pid field is a positive integer representing a thread ID, process ID, or process group ID. See F_SETOWN_EX for more details. 💜

🔥 F_SETOWN_EX

This one does a similar job to F_SETOWN, but glow-up edition: it lets the caller direct I/O availability signals to a specific thread, process, or process group. The caller specifies the target of the signals via arg, which is a pointer to a f_owner_ex structure. The type field has one of the following values, which define how pid gets interpreted:

F_OWNER_TID

Send the signal to the thread whose thread ID (the value returned by a call to clone(2) or gettid(2)) is specified in pid.

F_OWNER_PID

Send the signal to the process whose ID is specified in pid.

F_OWNER_PGRP

Send the signal to the process group whose ID is specified in pid. (Note that, unlike with F_SETOWN, a process group ID is specified as a positive value here. 🌟 plot twist!)

⭐ F_GETSIG

Returns (as the function result) the signal sent when input or output becomes possible. Read this bit twice, it's a little freaky:

• A value of zero means SIGIO is sent.
• Any other value (including SIGIO itself) is the signal sent instead — and in this case additional info is available to the signal handler if it was installed with SA_SIGINFO.

arg is ignored. Once again, just vibes, no job. 🙈

💫 F_SETSIG

Sets the signal sent when input or output becomes possible to the value given in arg.

• A value of zero means send the default SIGIO signal.
• Any other value (including SIGIO) is the signal to send instead — and in this case additional info is available to the signal handler if it was installed with SA_SIGINFO.

By using F_SETSIG with a nonzero value, and setting SA_SIGINFO for the signal handler (see sigaction(2)), extra information about I/O events gets passed to the handler in a siginfo_t structure. If the si_code field indicates the source is SI_SIGIO, the si_fd field gives the file descriptor associated with the event. Otherwise, there's no indication which file descriptors are pending, and you should use the usual mechanisms (select(2), poll(2), read(2) with O_NONBLOCK set, etc.) to figure out which file descriptors are available for I/O.

👀 Note that the file descriptor provided in si_fd is the one that was specified during the F_SETSIG operation. This can lead to a genuinely unhinged corner case: if the file descriptor is duplicated (dup(2) or similar), and the original file descriptor is closed, then I/O events will continue to be generated, but the si_fd field will contain the number of the now closed file descriptor. Haunted. 💀

By selecting a real time signal (value >= SIGRTMIN), multiple I/O events may be queued using the same signal numbers. (Queuing is dependent on available memory.) Extra information is available if SA_SIGINFO is set for the signal handler, as above.

Note that Linux imposes a limit on the number of real-time signals that may be queued to a process (see getrlimit(2) and signal(7)) and if this limit is reached, then the kernel reverts to delivering SIGIO, and this signal is delivered to the entire process rather than to a specific thread.

---

Using these mechanisms, a program can implement fully asynchronous I/O without using select(2) or poll(2) most of the time. Slay, honestly. 🔥

The use of O_ASYNC is specific to BSD and Linux. The only use of F_GETOWN and F_SETOWN specified in POSIX.1 is in conjunction with the use of the SIGURG signal on sockets. (POSIX does not specify the SIGIO signal.) F_GETOWN_EX, F_SETOWN_EX, F_GETSIG, and F_SETSIG are Linux-specific. POSIX has asynchronous I/O and the aio_sigevent structure to achieve similar things; these are also available in Linux as part of the GNU C Library (glibc).

🫶 RETURN VALUE

See fcntl(2). But also, the receipts:

F_GETOWN

Value of file descriptor owner.

F_GETSIG

Value of signal sent when read or write becomes possible, or zero for traditional SIGIO behavior.

F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_SETSIG

Zero. That's it. Zero. 🎯

On error, -1 is returned, and errno is set to indicate the error. !important

😭 ERRORS

See fcntl(2).

• EINVAL — op is F_SETSIG and arg is not an allowable signal number. bestie that's not a real signal number, try again 💅

👑 STANDARDS

F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX

POSIX.1-2024. Standards certified. ✨

F_GETSIG, F_SETSIG

Linux. (Define the _GNU_SOURCE macro to obtain these definitions.) Don't forget the macro, she's required. 🎀

📖 HISTORY

F_GETOWN, F_SETOWN

POSIX.1-2001. (To get their definitions, define either _XOPEN_SOURCE with the value 500 or greater, or _POSIX_C_SOURCE with the value 200809L or greater.) So many macro hoops, we jump through them though. 🦋

F_GETOWN_EX, F_SETOWN_EX

POSIX.1-2024. Linux 2.6.32. Ancient history in internet years. 🪦

F_GETSIG, F_SETSIG

Linux. That's the whole origin story. 💜

💀 BUGS

F_GETOWN

A limitation of the Linux system call conventions on some architectures (notably i386) means that if a (negative) process group ID to be returned by F_GETOWN falls in the range -1 to -4095, then the return value is wrongly interpreted by glibc as an error in the system call; that is, the return value of fcntl() will be -1, and errno will contain the (positive) process group ID. Ma'am. 😭

The Linux-specific F_GETOWN_EX operation avoids this problem. Since glibc 2.11, glibc makes the kernel F_GETOWN problem invisible by implementing F_GETOWN using F_GETOWN_EX. Workaround era, we love a fix. 🫶

F_SETOWN

In Linux 2.4 and earlier, there is a bug that can occur when an unprivileged process uses F_SETOWN to specify the owner of a socket file descriptor as a process (group) other than the caller. In this case, fcntl() can return -1 with errno set to EPERM, even when the owner process (group) is one that the caller has permission to send signals to. Despite this error return, the file descriptor owner is set, and signals will be sent to the owner. So the error is lying to you and the side effects happened anyway. classic. 💀

🔍 SEE ALSO

• fcntl(2) — the whole reason any of this exists, go read her next bestie

---

and that's the page!! 💖 this was pulled straight from Linux man-pages 6.20, dated 2025-12-31 — take a screenshot, tag yourself, and go set some signal handlers responsibly. ily, bye!! 🎀✨🦋