sysctl

sysctl is a software utility of some Unix-like operating systems that reads and modifies the attributes of the system kernel such as its version number, maximum limits, and security settings.[1] It is available both as a system call for compiled programs, and an administrator command for interactive use and scripting. Linux additionally exposes sysctl as a virtual file system.

Not to be confused with systemctl.
sysctl
Written inC
Operating systemUnix-like (BSD)
TypeSystem configuration

BSD

In BSD, these parameters are generally objects in a management information base (MIB) that describe tunable limits such as the size of a shared memory segment, the number of threads the operating system will use as an NFS client, or the maximum number of processes on the system; or describe, enable or disable behaviors such as IP forwarding, security restrictions on the superuser (the "securelevel"), or debugging output.[1]

In OpenBSD and DragonFly BSD, sysctl is also used as the transport layer for the hw.sensors framework for hardware monitoring,[2] whereas NetBSD uses the ioctl system call for its sysmon envsys counterpart. Both sysctl and ioctl are the two system calls which can be used to add extra functionality to the kernel without adding yet another system call;[3] for example, in 2004 with OpenBSD 3.6, when the tcpdrop utility was introduced, sysctl was used as the underlying system call.[3][4] In FreeBSD, although there is no sensors framework, the individual temperature and other sensors are still commonly exported through the sysctl tree through Newbus, for example, as is the case with the aibs(4) driver that's available in all the 4 BSD systems, including FreeBSD.[5][6][7]

In BSD, a system call or system call wrapper is usually provided for use by programs, as well as an administrative program and a configuration file (for setting the tunable parameters when the system boots).

This feature first appeared in 4.4BSD. It has the advantage over hardcoded constants that changes to the parameters can be made dynamically without recompiling the kernel.

Historically, although kernel variables themselves could be modified through sysctl, the elements comprising the MIB of the sysctl tree were hardcoded at compile time, and as of 2019, it's mostly still the case in OpenBSD (with some exceptions like hw.sensors, which manages and provides its own dynamic subtree). FreeBSD has had "sysctl internal magic" for dynamic sysctl tree management since 1995; NetBSD has had its own implementation of a dynamic sysctl tree since December 2003.[5][6]

Linux

In Linux, the sysctl interface mechanism is also exported as part of procfs under the /proc/sys directory (not to be confused with the /sys directory). This difference means checking the value of some parameter requires opening a file in a virtual file system, reading its contents, parsing them and closing the file. The sysctl system call does exist on Linux, but it has been deprecated and does not have a wrapper function in glibc; it is usually unavailable due to many distributions configuring the kernel without CONFIG_SYSCTL_SYSCALL; so it is not recommended for use.[8]

Examples

When IP forwarding is enabled, the operating system kernel will act as a router. In FreeBSD, NetBSD, OpenBSD, DragonFly BSD, and Darwin/Mac OS X, the parameter net.inet.ip.forwarding can be set to 1 to enable this behavior. In Linux, the parameter is called net.ipv4.ip_forward.

In most systems, the command sysctl -w parameter=1 will enable a certain behavior. This will persist until the next reboot. If the behavior should be enabled whenever the system boots, the line parameter=1 can be added/rewritten to the file /etc/sysctl.conf. Additionally, some sysctl variables cannot be modified after the system is booted. These variables (depending on the variable, the version and flavor of BSD) need to either be set statically in the kernel at compile time or set in /boot/loader.conf.

See also

References
  1. "sysctl(7) — system information variables". BSD Cross Reference. NetBSD.
  2. Constantine A. Murenin (2007-04-17). Generalised Interfacing with Microprocessor System Hardware Monitors. Proceedings of 2007 IEEE International Conference on Networking, Sensing and Control, 15–17 April 2007. London, United Kingdom: IEEE. pp. 901–906. doi:10.1109/ICNSC.2007.372901. ISBN 978-1-4244-1076-7. IEEE ICNSC 2007, pp. 901—906.
  3. Federico Biancuzzi (2004-10-28). "OpenBSD 3.6 Live". ONLamp. O'Reilly Media. Archived from the original on 2004-10-29. Retrieved 2019-03-20.
  4. Markus Friedl (2004). "tcpdrop.c". BSD Cross Reference. OpenBSD.
  5. Constantine A. Murenin; Raouf Boutaba (2009-03-17). "8.3. Sensors framework in FreeBSD CVS". OpenBSD Hardware Sensors Framework (PDF). AsiaBSDCon 2009 Proceedings, 12–15 March 2009. Tokyo University of Science, Tokyo, Japan (published 2009-03-14). Archived from the original on 2010-06-20. Retrieved 2019-03-04.{{cite conference}}: CS1 maint: bot: original URL status unknown (link)
  6. Constantine A. Murenin (2010-05-21). "8.3. Sensors framework in FreeBSD CVS". OpenBSD Hardware Sensors — Environmental Monitoring and Fan Control (MMath thesis). University of Waterloo: UWSpace. hdl:10012/5234. Document ID: ab71498b6b1a60ff817b29d56997a418.
  7. "aibs(4) — ASUSTeK AI Booster ACPI ATK0110 voltage, temperature and fan sensor". BSD Cross Reference. FreeBSD. 2010.
    • "aibs -- ASUSTeK AI Booster ACPI ATK0110 voltage, temperature and fan sensor". FreeBSD Manual Pages.
  8. "sysctl(2): read/write system parameters". man7.org. 2017-09-15. Retrieved 2018-01-04.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.