[DTrace-devel] [PATCH] libproc: make Psystem_daemon() detect modern systemd properly

Nick Alcock nick.alcock at oracle.com
Thu Jun 19 12:00:08 UTC 2025


On 18 Jun 2025, Kris Van Hees verbalised:

> On Fri, Jun 13, 2025 at 05:46:37PM +0100, Nick Alcock wrote:
>> Psystem_daemon() is used when carrying out shortlived grabs to detect
>> whether a process is too risky to carry out invasive grabs of (you wouldn't
>> usually want to stop syslogd or, God forbid, try to ptrace PID 1, unless
>> explicitly requested via -p: the process just coming up in routine probe
>> firing is not enough).
>> 
>> This has two code paths: a reliable one for systemd systems (which checks to
>> see if the process is in the system slice, which contains precisely and only
>> system daemons), and an unreliable one for other systems (which does the old
>> Unix approach of consdering anything in the user uid range or with a TTY or
>> with open standard FDs to TTYs to be not system daemons, and everything else
>> to possibly be one).
>> 
>> We were checking to see if a system was systemd by looking for the systemd
>> cgroup hierarchy name in any of the victim process's cgroups.  This was
>> reliable back in the days of cgroups v1, but alas in v2 where systemd runs
>> all the cgroups if it runs any and there are no longer multiple hierarchies,
>> systemd no longer names its cgroups this way and the test fails, causing us
>> to fall back to the unreliable pre-systemd approach.
>> 
>> Use a more reliable approach to detect systemd, the same approach used by
>> sd_booted() in libsystemd; check for the existence of the
>> /run/systemd/system directory.  Fix slice detection to work in the absence
>> of a systemd hierarchy name, and everything else works unchanged.
>
> Is /run/systems/system guaranteed to always be the correct path or is that
> configurable in systemd and thus could change depending on distro etc?

It's not configurable. I got the path from the manpage for sd_booted(3),
which also recommends just doing the check yourself directly :) so as
canonized as anything like this can be, much more so than the guesswork
we were doing before.



More information about the DTrace-devel mailing list