Quite a few places read an integer sysctl and parse it manually, each in
its own way: some via read_one_line_file() on a hand-built /proc/sys/
path, some via sysctl_read() followed by safe_atoX(), parse_boolean() or
even a plain string comparison, and parsing into various integer types
(int, unsigned, unsigned long, uint64_t).
Add three helpers, sysctl_read_int(), sysctl_read_unsigned() and
sysctl_read_uint64(), plus a sysctl_read_uint32() alias for
sysctl_read_unsigned() for places where the value is stored in a
strictly 32-bit type (such as uid_t/gid_t), and a sysctl_read_lu()
wrapper that maps to sysctl_read_uint32() or sysctl_read_uint64(),
depending on the size of unsigned long. Then port all these users over:
- kernel.cap_last_cap (cap_last_cap() and test-capability-util)
- kernel.random.poolsize (random_pool_size())
- fs.nr_open (read_nr_open())
- kernel.pid_max and kernel.threads-max (procfs_get_pid_max(),
procfs_get_threads_max())
- net.unix.max_dgram_qlen (PID 1's bump_unix_max_dgram_qlen())
- kernel.overflowuid and kernel.overflowgid (PID 1's taint logic)
- fs.protected_hardlinks (tmpfiles)
- kernel.apparmor_restrict_unprivileged_userns (test-execute)
Note that fs.protected_hardlinks is read as integer instead of boolean
now, since the kernel exposes it as such (even if it only accepts 0 and
1 for now). This matters even more for its siblings fs.protected_regular
and fs.protected_fifos which accept 0, 1 and 2, and hence cannot be
parsed via parse_boolean().
PID 1 keeps tainting itself if kernel.overflowuid/kernel.overflowgid
cannot be parsed, as before, but not if they cannot be read at all.
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release
