Skip to content

Improve dbus-daemon-launch-helper behaviour if it cannot write oom_score_adj

Simon McVittie requested to merge smcv/dbus:oom-score-adj into master

  • activation-helper: Never crash if unable to write oom_score_adj

    _dbus_warn() normally only logs a warning, but can be made fatal by environment variables. In particular, we do that during unit testing, which can result in a build-time test failure if dbus is built in a sandbox environment that prevents write access.

    _dbus_log() does only the logging part of _dbus_warn(), which seems more appropriate here.

  • sysdeps: Only open oom_score_adj read/write if we need to write it

    If we're running in a sandbox, we might not have write access to oom_score_adj. In the common case where we don't have any special protection from the OOM-killer, we can detect that with only read access, and skip the part where we open it for writing.

    (We would also not have write access to oom_score_adj if we're running with elevated Linux capabilities while not root, but that should never actually happen for dbus-daemon-launch-helper, which is setuid root for production use or has no capabilities during unit-testing.)

/cc @floppym

Not thoroughly tested yet. Would you be able to try this in your sandbox environment?

The result I would expect is that if you have only the first commit, it will log a warning open(/proc/self/oom_score_adj): Permission denied but the tests will still pass; and then if you add the second commit, the warning will also go away. The logged warning should end up in test/test-bus-launch-helper-oom.log if you're using 1.14.x, or somewhere more like test/test-bus-launch-helper.sh.log if you're applying these changes as patches to 1.12.x.

Edited by Simon McVittie

Merge request reports