SYSCTL(3)

Bestie, you're looking at SYSCTL(3) from the Library Functions Manual — aka the libc page for getting and setting system info, and it's honestly giving main character energy in the kernel-adjacent department. Let's go.

---

✨ NAME ✨

sysctl, sysctlbyname, sysctlnametomib — get or set system information. That's the whole three-name situation, and yes, they're all in the same friend group.

📚 LIBRARY 📚

Standard C Library (libc, -lc). Slay.

🛠️ SYNOPSIS 🛠️

The vibe check, exactly as the header says:

#include <sys/sysctl.h>

int
sysctl(const int *name, u_int namelen, void *oldp, size_t *oldlenp,
    const void *newp, size_t newlen);

int
sysctlbyname(const char *name, void *oldp, size_t *oldlenp,
    const void *newp, size_t newlen);

int
sysctlnametomib(const char *name, int *mibp, size_t *sizep);

💅 DESCRIPTION 💅

Okay so sysctl() retrieves system information and lets processes with appropriate privileges set system information. The info it can hand you consists of integers, strings, and tables — like a little buffet of kernel facts 🍓. You can also retrieve and set information from the command interface using the sysctl(8) utility. Obsessed.

Unless explicitly noted below, sysctl() returns a consistent snapshot of the data requested. Consistency is obtained by locking the destination buffer into memory so that the data may be copied out without blocking. Calls to sysctl() are serialized to avoid deadlock — yes, they queue politely, no chaos.

The state is described using a “Management Information Base” (MIB) style name, listed in name, which is a namelen length array of integers. If that sounds like a coordinate system for kernel data, that's because it lowkey is.

The sysctlbyname() function accepts an ASCII representation of the name and internally looks up the integer name vector. Apart from that, it behaves the same as the standard sysctl() function. Same energy, friendlier spelling ✨.

The information is copied into the buffer specified by oldp. The size of the buffer is given by the location specified by oldlenp before the call, and that location gives the amount of data copied after a successful call and after a call that returns with the error code ENOMEM. So oldlenp is doing double duty: size in, size out. Not me being impressed by a pointer 😭.

If the amount of data available is greater than the size of the buffer supplied, the call supplies as much data as fits in the buffer provided and returns with the error code ENOMEM. Translation: it fills what it can, then tells you the buffer was too small. If the old value is not desired, oldp and oldlenp should be set to NULL.

bestie warning: too-small buffer = partial data plus ENOMEM, not a full clean read. Handle it, don't ignore it 💅.

The size of the available data can be determined by calling sysctl() with the NULL argument for oldp. The size of the available data will be returned in the location pointed to by oldlenp. For some operations, the amount of space may change often. For these operations, the system attempts to round up so that the returned size is large enough for a call to return the data shortly thereafter. It's giving “I got you, but also data is feral.”

To set a new value, newp is set to point to a buffer of length newlen from which the requested value is to be taken. If a new value is not to be set, newp should be set to NULL and newlen set to 0. Clean 🎀.

The sysctlnametomib() function accepts an ASCII representation of the name, looks up the integer name vector, and returns the numeric representation in the mib array pointed to by mibp. The number of elements in the mib array is given by the location specified by sizep before the call, and that location gives the number of entries copied after a successful call. The resulting mib and size may be used in subsequent sysctl() calls to get the data associated with the requested ASCII name.

This interface is intended for use by applications that want to repeatedly request the same variable — and here's the flex — the sysctl() function runs in about a third the time as the same request made via the sysctlbyname() function. The sysctlnametomib() function is also useful for fetching mib prefixes and then adding a final component. For example, to fetch process information for processes with pid's less than 100:

int i, mib[4];
size_t len;
struct kinfo_proc kp;

/* Fill out the first three components of the mib */
len = 4;
sysctlnametomib("kern.proc.pid", mib, &len);

/* Fetch and print entries for pid's < 100 */
for (i = 0; i < 100; i++) {
        mib[3] = i;
        len = sizeof(kp);
        if (sysctl(mib, 4, &kp, &len, NULL, 0) == -1)
                perror("sysctl");
        else if (len > 0)
                printkproc(&kp);
}

The top level names are defined with a CTL_ prefix in <sys/sysctl.h>, and are as follows. The next and subsequent levels down are found in the include files listed here, and described in separate sections below. So here's the whole top-level lineup, no cap:

• CTL_DEBUG — next level names: <sys/sysctl.h>; description: Debugging.
• CTL_VFS — next level names: <sys/mount.h>; description: File system.
• CTL_HW — next level names: <sys/sysctl.h>; description: Generic CPU, I/O.
• CTL_KERN — next level names: <sys/sysctl.h>; description: High kernel limits.
• CTL_MACHDEP — next level names: <sys/sysctl.h>; description: Machine dependent.
• CTL_NET — next level names: <sys/socket.h>; description: Networking.
• CTL_USER — next level names: <sys/sysctl.h>; description: User-level.
• CTL_VM — next level names: <vm/vm_param.h>; description: Virtual memory.

For example, the following retrieves the maximum number of processes allowed in the system:

int mib[2], maxproc;
size_t len;

mib[0] = CTL_KERN;
mib[1] = KERN_MAXPROC;
len = sizeof(maxproc);
sysctl(mib, 2, &maxproc, &len, NULL, 0);

To retrieve the standard search path for the system utilities:

int mib[2];
size_t len;
char *p;

mib[0] = CTL_USER;
mib[1] = USER_CS_PATH;
sysctl(mib, 2, NULL, &len, NULL, 0);
p = malloc(len);
sysctl(mib, 2, p, &len, NULL, 0);

🐞 CTL_DEBUG 🐞

The debugging variables vary from system to system. A debugging variable may be added or deleted without need to recompile sysctl() to know about it. Each time it runs, sysctl() gets the list of debugging variables from the kernel and displays their current values. The system defines twenty (struct ctldebug) variables named debug0 through debug19. They are declared as separate variables so that they can be individually initialized at the location of their associated variable. The loader prevents multiple use of the same variable by issuing errors if a variable is initialized in more than one place. For example, to export the variable dospecialcheck as a debugging variable, the following declaration would be used:

int dospecialcheck = 1;
struct ctldebug debug5 = { "dospecialcheck", &dospecialcheck };

🗂️ CTL_VFS 🗂️

A distinguished second level name, VFS_GENERIC, is used to get general information about all file systems. One of its third level identifiers is VFS_MAXTYPENUM that gives the highest valid file system type number. Its other third level identifier is VFS_CONF that returns configuration information about the file system type given as a fourth level identifier (see getvfsbyname(3) as an example of its use). The remaining second level identifiers are the file system type number returned by a statfs(2) call or from VFS_CONF. The third level identifiers available for each file system are given in the header file that defines the mount argument structure for that file system. Very “bring your own header file” of it 🦋.

🖥️ CTL_HW 🖥️

The string and integer information available for the CTL_HW level is detailed below. The changeable column shows whether a process with appropriate privilege may change the value. (Spoiler: in this list, none of them are changeable — they're all “no” bestie.)

• HW_MACHINE — type: string; changeable: no.
• HW_MODEL — type: string; changeable: no.
• HW_NCPU — type: integer; changeable: no.
• HW_BYTEORDER — type: integer; changeable: no.
• HW_PHYSMEM — type: integer; changeable: no.
• HW_USERMEM — type: integer; changeable: no.
• HW_PAGESIZE — type: integer; changeable: no.
• HW_FLOATINGPT — type: integer; changeable: no.
• HW_MACHINE_ARCH — type: string; changeable: no.
• HW_REALMEM — type: integer; changeable: no.
• HW_AVAILPAGES — type: integer; changeable: no.

And here's what each one actually means, because the names alone are lowkey cryptic:

• HW_MACHINE — The machine class.
• HW_MODEL — The machine model.
• HW_NCPU — The number of cpus.
• HW_BYTEORDER — The byteorder (4321 or 1234).
• HW_PHYSMEM — Amount of physical memory (in bytes), minus the amount used by the kernel, pre-loaded modules, and (on x86) the dcons buffer.
• HW_USERMEM — Amount of memory (in bytes) which is not wired.
• HW_PAGESIZE — The software page size.
• HW_FLOATINGPT — Nonzero if the floating point support is in hardware.
• HW_MACHINE_ARCH — The machine dependent architecture type.
• HW_REALMEM — Amount of memory (in bytes) reported by the firmware. That value is sometimes not sane; in that case, the kernel reports the max memory address instead.
• HW_AVAILPAGES — The same value as HW_PHYSMEM, measured in pages rather than bytes.

🧠 CTL_KERN 🧠

The string and integer information available for the CTL_KERN level is detailed below. The changeable column shows whether a process with appropriate privilege may change the value. The types of data currently available are process information, system vnodes, the open file entries, routing table entries, virtual memory statistics, load average history, and clock rate information.

okay so here’s the second-level name roster, bestie — every single one, with its type and whether you can change it, no skips, periodt:

• KERN_ARGMAX — type: integer · changeable: no
• KERN_ARND — type: integer · changeable: no
• KERN_BOOTFILE — type: string · changeable: yes
• KERN_BOOTTIME — type: struct timeval · changeable: no
• KERN_CLOCKRATE — type: struct clockinfo · changeable: no
• KERN_FILE — type: struct xfile · changeable: no
• KERN_HOSTID — type: integer · changeable: yes
• KERN_HOSTUUID — type: string · changeable: yes
• KERN_HOSTNAME — type: string · changeable: yes
• KERN_IOV_MAX — type: integer · changeable: yes
• KERN_JOB_CONTROL — type: integer · changeable: no
• KERN_LOCKF — type: struct kinfo_lockf · changeable: no
• KERN_LOGSIGEXIT — type: integer · changeable: yes
• KERN_MAXFILES — type: integer · changeable: yes
• KERN_MAXFILESPERPROC — type: integer · changeable: yes
• KERN_MAXPHYS — type: integer · changeable: no
• KERN_MAXPROC — type: integer · changeable: no
• KERN_MAXPROCPERUID — type: integer · changeable: yes
• KERN_MAXVNODES — type: integer · changeable: yes
• KERN_NGROUPS — type: integer · changeable: no
• KERN_NISDOMAINNAME — type: string · changeable: yes
• KERN_OSRELDATE — type: integer · changeable: no
• KERN_OSRELEASE — type: string · changeable: no
• KERN_OSREV — type: integer · changeable: no
• KERN_OSTYPE — type: string · changeable: no
• KERN_POSIX1 — type: integer · changeable: no
• KERN_PROC — type: node · changeable: not applicable
• KERN_PS_STRINGS — type: integer · changeable: no
• KERN_SAVED_IDS — type: integer · changeable: no
• KERN_SECURELVL — type: integer · changeable: raise only
• KERN_UPDATEINTERVAL — type: integer · changeable: no
• KERN_USRSTACK — type: integer · changeable: no
• KERN_VERSION — type: string · changeable: no

---

KERN_ARGMAX — the maximum bytes of argument to execve(2).

KERN_ARND — arc4rand(9) fills the buffer with random bytes from the in-kernel random data generator. This is an alternative interface for read(2) of the random(4) device, which does not depend on accessibility and correct mounting options of the devfs(4) node.

KERN_BOOTFILE — the full pathname of the file from which the kernel was loaded.

KERN_BOOTTIME — a struct timeval structure is returned. This structure contains the time that the system was booted.

KERN_CLOCKRATE — a struct clockinfo structure is returned. This structure contains the clock, statistics clock and profiling clock frequencies, the number of micro-seconds per hz tick and the skew rate.

KERN_FILE — return the entire file table. The returned data consists of an array of struct xfile, whose size depends on the current number of such objects in the system.

KERN_HOSTID — get or set the host ID.

KERN_HOSTUUID — get or set the host’s universally unique identifier (UUID).

KERN_HOSTNAME — get or set the hostname.

KERN_IOV_MAX — the maximum accepted number of elements in an input-output vector (iovec), see readv(2) and writev(2).

KERN_JOB_CONTROL — return 1 if job control is available on this system, otherwise 0.

KERN_LOCKF — returns the list of the file advisory locks currently known to kernel.

KERN_LOGSIGEXIT — controls logging of process exit due to untrapped signals.

KERN_MAXFILES — the maximum number of files that may be open in the system.

KERN_MAXFILESPERPROC — the maximum number of files that may be open for a single process. This limit only applies to processes with an effective uid of nonzero at the time of the open request. Files that have already been opened are not affected if the limit or the effective uid is changed.

KERN_MAXPHYS — specifies the maximum block I/O size. Can be changed by the tunable kern.maxphys.

KERN_MAXPROC — the maximum number of concurrent processes the system will allow.

KERN_MAXPROCPERUID — the maximum number of concurrent processes the system will allow for a single effective uid. This limit only applies to processes with an effective uid of nonzero at the time of a fork request. Processes that have already been started are not affected if the limit is changed.

KERN_MAXVNODES — the maximum number of vnodes available on the system.

KERN_NGROUPS — the maximum number of supplemental groups.

KERN_NISDOMAINNAME — the name of the current YP/NIS domain.

KERN_OSRELDATE — the kernel release version in the format MmmRxx, where M is the major version, mm is the two digit minor version, R is 0 if release branch, otherwise 1, and xx is updated when the available APIs change.

The userland release version is available from <osreldate.h>; parse this file if you need to get the release version of the currently installed userland.

KERN_OSRELEASE — the system release string.

KERN_OSREV — the system revision string.

KERN_OSTYPE — the system type string.

KERN_POSIX1 — the version of IEEE Std 1003.1 (“POSIX.1”) with which the system attempts to comply.

KERN_PROC — return selected information about specific running processes.

For the following names, an array of struct kinfo_proc structures is returned, whose size depends on the current number of such objects in the system:

• KERN_PROC_ALL — fourth level: None
• KERN_PROC_PID — fourth level: A process ID
• KERN_PROC_PGRP — fourth level: A process group
• KERN_PROC_SESSION — fourth level: A session
• KERN_PROC_TTY — fourth level: A tty device
• KERN_PROC_UID — fourth level: effective user ID
• KERN_PROC_RUID — fourth level: A real user ID
• KERN_PROC_GID — fourth level: effective group ID
• KERN_PROC_RGID — fourth level: A real group ID

For the following names, the miscellaneous information about the target process, which is specified by the fourth level of the oid name, is returned. A process ID of -1 specifies the current process.

• KERN_PROC_ARGS — fourth level: Set of strings
• KERN_PROC_PATHNAME — fourth level: String
• KERN_PROC_KSTACK — fourth level: struct kinfo_stack []
• KERN_PROC_VMMAP — fourth level: struct kinfo_vmentry []
• KERN_PROC_FILEDESC — fourth level: struct kinfo_file []
• KERN_PROC_GROUPS — fourth level: gid_t []
• KERN_PROC_ENV — fourth level: Set of strings
• KERN_PROC_AUXV — fourth level: Elf_Auxinfo []
• KERN_PROC_RLIMIT — fourth level: Integer
• KERN_PROC_PS_STRINGS — fourth level: Integer
• KERN_PROC_UMASK — fourth level: Integer/short
• KERN_PROC_OSREL — fourth level: Integer
• KERN_PROC_SIGTRAMP — fourth level: Integer
• KERN_PROC_CWD — fourth level: String
• KERN_PROC_NFDS — fourth level: Integer
• KERN_PROC_SIGFASTBLK — fourth level: Integer
• KERN_PROC_VM_LAYOUT — fourth level: struct kinfo_vm_layout
• KERN_PROC_RLIMIT_USAGE — fourth level: rlim_t []
• KERN_PROC_KQUEUE — fourth level: struct kinfo_knote []

KERN_PROC_ARGS — the command line argument array is returned in a flattened form, i.e., zero-terminated arguments follow each other. The total size of array is returned. It is also possible for a process to set its own process title this way.

KERN_PROC_PATHNAME — the path of the process’ text file is returned.

KERN_PROC_KSTACK — the in-kernel call stacks for the threads of the specified process.

KERN_PROC_VMMAP — the description of the map entries for the process. Also refer to kinfo_getvmmap(3).

KERN_PROC_FILEDESC — the file descriptors for files opened in the specified process. Also refer to kinfo_getfile(3).

KERN_PROC_GROUPS — groups associated with the process.

KERN_PROC_ENV — the set of strings representing the environment of the specified process. 🫶

okay so real talk from the kernel's POV: environment only exists at the moment of the execve(2) system call. this node method tries to reconstruct the env from the breadcrumbs left behind in the process address space, but ngl it is not guaranteed to succeed, and it is not guaranteed to show you the current value the program is actually keeping. 💀

• KERN_PROC_AUXV — the set of ELF auxv entries ✨. see the note above about environment, because it applies here too — same vibes, same caveats.
• KERN_PROC_RLIMIT — you must supply an additional OID name element specifying the resource name as in getrlimit(2). the call returns the given resource limit for the process 🫶.
• KERN_PROC_PS_STRINGS — returns the location of the ps_strings structure at the time of the last call to execve(2) in the specified process 👑
• KERN_PROC_UMASK — the current umask value, see umask(2) 🎀
• KERN_PROC_OSREL — the value of osrel for the process, i.e. the osrel the currently executed image was compiled for. it's read from the note of the elf executable at execve(2) time. it might be modified by the process (they can be messy like that) 🙈
• KERN_PROC_SIGTRAMP — address of the signal trampoline in the process address space, where — simplifying a lot — the kernel passes control for signal delivery 🌸
• KERN_PROC_CWD — returns the current working directory for the process 🦋
• KERN_PROC_NFDS — returns the total number of opened file descriptors for the process 🔥
• KERN_PROC_SIGFASTBLK — returns the address of the sigfastblock(2) location, if active ✨
• KERN_PROC_VM_LAYOUT — fills a structure describing the process virtual address space layout 🧚
• KERN_PROC_RLIMIT_USAGE — like KERN_PROC_RLIMIT, but instead of the limit it returns the accounted resource usage 💅. for resources that don't have a meaningful current value, -1 is returned.
• KERN_PROC_KQUEUE — fills an array of structures describing events registered with the specified kqueue 👑. the next two node's values are the pid and kqfd — the process ID of the process, and the file descriptor of the kqueue in that process, to query.

---

KERN_PS_STRINGS 🎀

Reports the location of the process ps_strings structure after exec, for the ABI of the querying process 💖

KERN_SAVED_IDS 🌈

Returns 1 if saved set-group and saved set-user ID is available, otherwise... well, that's the whole test ✨

KERN_SECURELVL 🔒

The system security level. this level may be raised by processes with appropriate privilege, but it may not be lowered 😤 periodt. no take-backs.

KERN_USRSTACK 🫶

Reports the top of the main thread user stack for the current process.

KERN_VERSION ⭐

The system version string. iconic. show-off behavior.

---

🌐 CTL_NET

the string and integer info available at the CTL_NET level is detailed below bestie. the changeable column tells you whether a process with appropriate privilege can change the value:

• PF_ROUTE — routing messages — not changeable 🚫
• PF_INET — IPv4 values — changeable ✅
• PF_INET6 — IPv6 values — changeable ✅

🛣️ PF_ROUTE

Return the entire routing table, or just a subset of it. the data comes back as a sequence of routing messages (see route(4) for the header file, format and meaning) 💜. the length of each message is contained in the message header, iykyk.

The third level name is a protocol number, which is currently always 0. the fourth level name is an address family, and you can set it to 0 to select all address families 🌈. the fifth, sixth and seventh level names go like this:

• NET_RT_FLAGS — sixth level: rtflags — seventh level: None
• NET_RT_DUMP — sixth level: None — seventh level: None or fib number
• NET_RT_IFLIST — sixth level: 0 or if_index — seventh level: None
• NET_RT_IFMALIST — sixth level: 0 or if_index — seventh level: None
• NET_RT_IFLISTL — sixth level: 0 or if_index — seventh level: None
• NET_RT_NHOPS — sixth level: None — seventh level: fib number

The NET_RT_IFMALIST name returns info about multicast group memberships on all interfaces if 0 is specified, or for the interface specified by if_index 🦋

The NET_RT_IFLISTL is like NET_RT_IFLIST, just returning message header structs with additional fields allowing the interface to be extended without breaking binary compatibility ✨. NET_RT_IFLISTL uses the 'l' versions of the message header structures: struct if_msghdrl and struct ifa_msghdrl.

NET_RT_NHOPS returns all nexthops for the specified address family in the given fib 👑

📡 PF_INET

Get or set various global info about IPv4 (Internet Protocol version 4) 💖. the third level name is the protocol, the fourth level name is the variable name. here's the currently defined values, no cap:

• icmp.bmcastecho — type: integer — changeable: yes
• icmp.maskrepl — type: integer — changeable: yes
• ip.forwarding — type: integer — changeable: yes
• ip.redirect — type: integer — changeable: yes
• ip.ttl — type: integer — changeable: yes
• udp.checksum — type: integer — changeable: yes

and here's what each one actually means 💅:

• icmp.bmcastecho — returns 1 if an ICMP echo request to a broadcast or multicast address is to be answered 🙈
• icmp.maskrepl — returns 1 if ICMP network mask requests are to be answered 🎀
• ip.forwarding — returns 1 when IP forwarding is enabled for the host, meaning the host is acting as a router 👑
• ip.redirect — returns 1 when ICMP redirects may be sent by the host. this option is ignored unless the host is routing IP packets, and it should normally be enabled on all systems ⭐
• ip.ttl — the maximum time-to-live (hop count) value for an IP packet sourced by the system 🌸. this value applies to normal transport protocols, not to ICMP.
• udp.checksum — returns 1 when UDP checksums are being computed and checked. disabling UDP checksums is strongly discouraged 🚨 like bestie please don't.

for variables net.inet.*.ipsec, please refer to ipsec(4) 🫶

🌐 PF_INET6

Get or set various global info about IPv6 (Internet Protocol version 6) 💜. the third level name is the protocol, the fourth level name is the variable name.

For variables net.inet6.* please refer to inet6(4) ✨. For variables net.inet6.*.ipsec6, please refer to ipsec(4).

---

👤 CTL_USER

the string and integer info available at the CTL_USER level is detailed below. the changeable column shows whether a process with appropriate privilege may change the value — spoiler, none of these are changeable, they're all read-only queens 👑:

• USER_BC_BASE_MAX — integer — no
• USER_BC_DIM_MAX — integer — no
• USER_BC_SCALE_MAX — integer — no
• USER_BC_STRING_MAX — integer — no
• USER_COLL_WEIGHTS_MAX — integer — no
• USER_CS_PATH — string — no
• USER_EXPR_NEST_MAX — integer — no
• USER_LINE_MAX — integer — no
• USER_LOCALBASE — string — no
• USER_POSIX2_CHAR_TERM — integer — no
• USER_POSIX2_C_BIND — integer — no
• USER_POSIX2_C_DEV — integer — no
• USER_POSIX2_FORT_DEV — integer — no
• USER_POSIX2_FORT_RUN — integer — no
• USER_POSIX2_LOCALEDEF — integer — no
• USER_POSIX2_SW_DEV — integer — no
• USER_POSIX2_UPE — integer — no
• USER_POSIX2_VERSION — integer — no
• USER_RE_DUP_MAX — integer — no
• USER_STREAM_MAX — integer — no
• USER_TZNAME_MAX — integer — no

okay now the actual definitions, one by one 💖:

🧮 USER_BC_BASE_MAX

The maximum ibase/obase values in the bc(1) utility.

🧮 USER_BC_DIM_MAX

The maximum array size in the bc(1) utility.

🧮 USER_BC_SCALE_MAX

The maximum scale value in the bc(1) utility.

🧮 USER_BC_STRING_MAX

The maximum string length in the bc(1) utility.

🌍 USER_COLL_WEIGHTS_MAX

The maximum number of weights that can be assigned to any entry of the LC_COLLATE order keyword in the locale definition file 🦋

🛤️ USER_CS_PATH

Return a value for the PATH environment variable that finds all the standard utilities ✨

🧠 USER_EXPR_NEST_MAX

The maximum number of expressions that can be nested within parenthesis by the expr(1) utility. deep nesting? she said know your limits.

📏 USER_LINE_MAX

The maximum length in bytes of a text-processing utility's input line.

📦 USER_LOCALBASE

Return the value of localbase that has been compiled into system utilities that need to have access to resources provided by a port or package 🎀

🖥️ USER_POSIX2_CHAR_TERM

Return 1 if the system supports at least one terminal type capable of all operations described in IEEE Std 1003.2 ("POSIX.2"), otherwise 0 💅

🖥️ USER_POSIX2_C_BIND

Return 1 if the system's C-language development facilities support the C-Language Bindings Option, otherwise 0 ✨

🖥️ USER_POSIX2_C_DEV

Return 1 if the system supports the C-Language Development Utilities Option, otherwise 0 🌸

🖥️ USER_POSIX2_FORT_DEV

Return 1 if the system supports the FORTRAN Development Utilities Option, otherwise 0 🔥

🖥️ USER_POSIX2_FORT_RUN

Return 1 if the system supports the FORTRAN Runtime Utilities Option, otherwise 0 ⭐

🖥️ USER_POSIX2_LOCALEDEF

Return 1 if the system supports the creation of locales, otherwise 0 🌈

🖥️ USER_POSIX2_SW_DEV

Return 1 if the system supports the Software Development Utilities Option, otherwise 0 👑

🌸 the user-level identifiers, continued 🌸

• USER_POSIX2_UPE — returns 1 if the system supports the User Portability Utilities Option, otherwise 0. yes bestie it's a vibe check for POSIX 💅
• USER_POSIX2_VERSION — the version of IEEE Std 1003.2 (“POSIX.2”) that the system is attempting to comply with. key word attempting 😭
• USER_RE_DUP_MAX — the maximum number of repeated occurrences of a regular expression that's permitted when you're using interval notation. so like {n,m} energy 🎀
• USER_STREAM_MAX — the minimum maximum number of streams a process may have open at any one time. yes, "minimum maximum", it's giving oxymoron but it's real ✨
• USER_TZNAME_MAX — the minimum maximum number of types supported for the name of a timezone. 🕰️

---

🔥 CTL_VM 🔥

okay so the string and integer info available at the CTL_VM level is all spelled out below, no gatekeeping. the changeable column tells you whether a process with appropriate privilege can actually change the value — like, do you have the range to touch it or nah 👑

• VM_LOADAVG — type struct loadavg, changeable: no
• VM_TOTAL — type struct vmtotal, changeable: no
• VM_SWAPPING_ENABLED — type integer, changeable: maybe
• VM_V_FREE_MIN — type integer, changeable: yes
• VM_V_FREE_RESERVED — type integer, changeable: yes
• VM_V_FREE_TARGET — type integer, changeable: yes
• VM_V_INACTIVE_TARGET — type integer, changeable: yes
• VM_V_PAGEOUT_FREE_MIN — type integer, changeable: yes
• VM_OVERCOMMIT — type integer, changeable: yes

the individual VM identifiers, one by one 💜

• VM_LOADAVG — returns the load average history. what you get back is a struct loadavg. history class for your CPU 📈
• VM_TOTAL — returns the system wide virtual memory statistics. what you get back is a struct vmtotal. the whole system's memory receipts 🧾
• VM_SWAPPING_ENABLED — 1 if process swapping is enabled, or 0 if it's disabled. tiny caveat bestie: this variable is permanently set to 0 if the kernel was built with swapping disabled. so no takebacks 🙈
• VM_V_FREE_MIN — the minimum amount of memory (cache memory plus free memory) that has to be available before a process waiting on memory will get awakened. like the bare minimum to be let back in the group chat 😴
• VM_V_FREE_RESERVED — processes will awaken the pageout daemon and wait for memory if the number of free and cached pages drops below this value. the panic button number 🚨
• VM_V_FREE_TARGET — the total amount of free memory (cache memory included) that the pageout daemon tries to maintain. its little goal in life 🎯
• VM_V_INACTIVE_TARGET — the desired number of inactive pages the pageout daemon should achieve when it runs. inactive pages can be quickly inserted into process address space when needed, so it's lowkey a stash 🗂️
• VM_V_PAGEOUT_FREE_MIN — if the amount of free and cache memory falls below this value, the pageout daemon enters "memory conserving mode" to avoid deadlock. emergency era 💀
• VM_OVERCOMMIT — overcommit behaviour, as described in tuning(7). go read that one for the tea 🍵

---

✨ RETURN VALUES ✨

upon successful completion, the value 0 is returned. otherwise the value -1 is returned and the global variable errno is set to indicate the error. classic zero-or-negative-one situation, no in between 🫶

---

🎀 FILES 🎀

• <sys/sysctl.h> — definitions for top level identifiers, second level kernel and hardware identifiers, and user level identifiers
• <sys/socket.h> — definitions for second level network identifiers
• <sys/gmon.h> — definitions for third level profiling identifiers
• <vm/vm_param.h> — definitions for second level virtual memory identifiers
• <netinet/in.h> — definitions for third level IPv4/IPv6 identifiers and fourth level IPv4/v6 identifiers
• <netinet/icmp_var.h> — definitions for fourth level ICMP identifiers
• <netinet/icmp6.h> — definitions for fourth level ICMPv6 identifiers
• <netinet/udp_var.h> — definitions for fourth level UDP identifiers

---

💀 ERRORS 💀

these are the errors that may be reported, read them like a warning label bestie:

• [EFAULT] — the buffer name, oldp, newp, or length pointer oldlenp contains an invalid address.
• [EINVAL] — the name array is less than two or greater than CTL_MAXNAME.
• [EINVAL] — a non-null newp is given and its specified length in newlen is too large or too small.
• [ENOMEM] — the length pointed to by oldlenp is too short to hold the requested value.
• [ENOMEM] — the smaller of either the length pointed to by oldlenp or the estimated size of the returned data exceeds the system limit on locked memory.
• [ENOMEM] — locking the buffer oldp, or a portion of the buffer if the estimated size of the data to be returned is smaller, would cause the process to exceed its per-process locked memory limit.
• [ENOTDIR] — the name array specifies an intermediate rather than terminal name.
• [EISDIR] — the name array specifies a terminal name, but the actual name is not terminal.
• [ENOENT] — the name array specifies a value that is unknown.
• [EPERM] — an attempt is made to set a read-only value. rude honestly 🙄
• [EPERM] — a process without appropriate privilege attempts to set a value. no privilege, no entry, that's the rule 💅

---

🌈 SEE ALSO 🌈

confstr(3), kinfo_getproc(3), kvm(3), sysconf(3), sysctl(8)

---

⭐ HISTORY ⭐

the sysctl() function first appeared in 4.4BSD. an icon, a legend, a pioneer 👑

---

and that's the whole page bestie, you ate that 🫶 this one's from the Debian crew, dated July 31, 2025, and it's SYSCTL(3) — go forth and sysctl responsibly ✨💖