Home / Alt manpages / proc_sys_abi(5)

  • proc_sys_abi(5)
  • File format
  • linux

Read and Safely Test /proc/sys/abi/vsyscall32

You will identify which ABI settings this kernel exposes, read vsyscall32, and, where the file exists and you have a maintenance window, make a temporary change with a recorded way back. This guide uses the installed Linux man-pages 6.7 documentation on an Ubuntu 6.8.0-139-generic kernel. Allow about ten minutes. The normal inspection steps are unprivileged; changing a kernel setting requires elevated privileges.

1. Check whether the ABI directory exists

The proc_sys_abi(5) page documents /proc/sys/abi/ as a directory that may contain application binary information. It is not guaranteed to be present on every system, so check before naming a file:

$ test -d /proc/sys/abi && printf '%s\n' 'ABI sysctl directory is present' || printf '%s\n' 'ABI sysctl directory is absent'

On a present directory, list the files without changing anything:

$ find /proc/sys/abi -maxdepth 1 -type f -printf '%f\n' | sort
vsyscall32

Your list may be empty or may contain different entries. Do not assume that a setting mentioned in an online example exists on this kernel.

Checkpoint

Continue only if the directory and the particular file you need both exist.

2. Read the setting directly

Read the file as an ordinary user. The kernel supplies the value followed by a newline:

$ cat /proc/sys/abi/vsyscall32
1

In the current kernel documentation, vsyscall32 controls whether a vDSO page is mapped into 32-bit processes. A value of 1 enables that mapping and 0 disables it. The documented default is enabled when the kernel has CONFIG_COMPAT_VDSO, otherwise disabled. This is a compatibility setting, not a general switch for 64-bit vDSO support.

For scripts, the procps sysctl command gives the same value with a name that is easier to include in status output:

$ sysctl abi.vsyscall32
abi.vsyscall32 = 1
$ sysctl -n abi.vsyscall32
1

The two commands are read-only. The -n form prints only the value, which is useful for a comparison:

value=$(sysctl -n abi.vsyscall32) || exit 1
case "$value" in
    0|1) printf 'vsyscall32=%s\n' "$value" ;;
    *) printf 'unexpected vsyscall32 value: %s\n' "$value" >&2; exit 2 ;;
esac

3. Relate the file to the kernel boot option

The upstream ABI documentation says that this setting controls the same behaviour as the x86 vdso32 kernel boot parameter. That relationship explains why a value can reflect an early boot decision rather than a local application configuration file. It does not mean that writing the sysctl edits the boot loader or changes the next boot.

Check the running kernel and its command line as read-only diagnostics:

$ uname -r
6.8.0-139-generic
$ tr ' ' '\n' < /proc/cmdline | grep '^vdso32$' || printf '%s\n' 'vdso32 is not present on the command line'

An absent boot parameter is not proof of the effective default, because the kernel configuration also matters. Treat /proc/sys/abi/vsyscall32 as the value currently in force.

4. If testing is necessary, record the old value first

Warning

Writing this setting changes kernel behaviour for 32-bit processes on the running host. It can break compatibility assumptions and may affect services without restarting them. Do this only with a clear test purpose, a maintenance window, and a recovery path. Do not change it on a production host merely to see what happens.

Capture the current value in a shell variable, and refuse to continue if it is not the documented binary form:

old_value=$(cat /proc/sys/abi/vsyscall32) || exit 1
case "$old_value" in
    0|1) printf 'recorded old value: %s\n' "$old_value" ;;
    *) printf 'unexpected old value: %s\n' "$old_value" >&2; exit 2 ;;
esac

Now, and only if the test is authorised, write the alternate value with sysctl:

$ sudo sysctl -w abi.vsyscall32=0
abi.vsyscall32 = 0

This is the first command in the guide that normally needs sudo. The command writes the live sysctl; it does not create a persistent configuration file. Verify immediately:

$ sysctl -n abi.vsyscall32
0

If the write is rejected, keep the error and investigate the host's permissions and kernel support. Do not repeatedly retry with different values.

5. Restore the recorded value

Restore the exact value captured before the test. If you opened a new shell, replace OLD_VALUE with the value you recorded, not a guessed default:

$ sudo sysctl -w abi.vsyscall32=OLD_VALUE
abi.vsyscall32 = OLD_VALUE
$ sysctl -n abi.vsyscall32
OLD_VALUE

For a same-shell test, the safer form uses the saved variable:

sudo sysctl -w "abi.vsyscall32=$old_value"
test "$(sysctl -n abi.vsyscall32)" = "$old_value"

There is no service restart or file deletion to undo here. The recovery action is the explicit write back to the recorded value. A reboot may also reapply the kernel's boot-time choice, but do not reboot a shared host as a substitute for restoring and verifying the setting.

6. Avoid the common interpretation errors

  • /proc/sys/abi/ is a kernel interface, not a directory of application binaries or a place to store configuration files.
  • A missing directory or file is a supported observation. It does not justify creating one with mkdir or placing a similarly named file elsewhere.
  • vsyscall32=1 describes the mapping setting. It does not prove that a 32-bit application starts successfully, that a process uses the page, or that other compatibility interfaces work.
  • The man page gives the directory purpose and points to kernel documentation; it does not promise a fixed list of files. Follow the running kernel's exposed interface.
  • Do not confuse the live write with persistence. If the setting must survive a reboot, establish the distribution's supported boot or sysctl configuration separately and test its precedence before changing it.

Done means

  • You checked whether /proc/sys/abi/ exists before using a path beneath it.
  • You listed the files and read the actual value of vsyscall32 on the running kernel.
  • You understand that 1 enables, and 0 disables, the 32-bit vDSO mapping when this setting is exposed.
  • If you tested a change, you recorded the old value, used elevated privileges deliberately, and restored and verified it.