Negative OOM score adjustment not reset to zero for activated system services

Steps to reproduce

• Install a test VM that boots using systemd. I used a Debian 10 VM generated by autopkgtest-build-qemu.
• Check that /lib/systemd/system/dbus.service has OOMScoreAdjust=-900.
• Install a D-Bus system service that does not have SystemdService in its D-Bus .service file, so that it will use traditional activation via dbus-daemon-launch-helper. I used system-tools-backends, which includes a service org.freedesktop.SystemToolsBackends.Platform.
• Start the service: dbus-send --system --print-reply org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.StartServiceByName string:org.freedesktop.SystemToolsBackends.Platform uint32:0
• Inspect /proc/${pid}/oom_score_adj for dbus-daemon --system
• Inspect /proc/${pid}/oom_score_adj for the activated service

Expected result

• dbus-daemon --system is running with OOM score adjustment of -900, meaning it is protected from the OOM killer
• SystemToolsBackends.pl is running with OOM score adjustment of 0, meaning it is not protected from the OOM killer

Actual result

Both are running with OOM score adjustment of -900. No warnings are logged.

Additional information

If I use strace -ff -p${pid} as root to attach to the system dbus-daemon, I can see the reason this happens: after the dbus-daemon has forked, it tries to open /proc/self/oom_score_adj as write-only, but gets EACCES "Permission denied".

This appears to be because the dbus-daemon initially started as root, and then dropped privileges to messagebus. This leaves most of the process parameter pseudo-files in /proc/self/oom_score_adj owned by root and inaccessible by messagebus. The forked child inherits this status.

Workaround

Configure system services with SystemdService=... so that they are started by systemd activation instead of traditional activation. This means they are run by a real service manager (systemd), instead of by the dbus-daemon, which does a minimal amount of vestigial service-management.