By analyzing slurmd.service
You know where slurmd.service is. Most likely what you seek will be in a line containing ExecStart=. To print this line:
grep ExecStart= /usr/lib/systemd/system/slurmd.service
If you want, you can examine the whole file:
less /usr/lib/systemd/system/slurmd.service
and analyze it.
You explicitly asked for the path of slurmd binary. In general what you find may or may not be a binary executable. E.g. it may be a shell script that eventually executes a binary executable (or not; in general a shell script itself may be a service). Use file /path/to/result to know if the result is binary.
With find
Without any clue from slurmd.service or so, this is a way to find regular files named slurmd that are executable to their owners:
find / -xdev -type f -name slurmd -perm -0100
-xdev makes find not descend into other filesystems. The point is we don't want to check /dev, /proc or /sys. It is sane to assume slurmd is in the root filesystem, but if your setup is more exotic then you may want the following command that does not use -xdev and excludes few directories explicitly:
find / -path /dev -prune -o -path /proc -prune -o -path /sys -prune -o \
-type f -name slurmd -perm -0100 -print
In general the file you want to find may be a symbolic link named slurmd, whose final target is an executable named whatever. To find such links, run:
find / -xdev -type l -name slurmd -exec sh -c '
find "$(realpath "$1")" -prune -type f -perm -0100 | grep -q .
' find-sh {} \; -print
Use realpath /path/to/result to see the final target of the result.
Like above, what you find may or may not be binary executable(s).
By finding the process
When the service is running, you can check its status with:
systemctl status slurmd.service
It will tell you the main PID (among other things).
Alternatively, when slurmd is running (as (a part of) the service or in whatever way), this (non-portable) command will show you its PID:
pgrep '^slurmd$'
Or with portable tools you can do this:
ps -A -o 'pid comm' | grep 'slurmd'
Once you know the PID, check
ls -l /proc/PID/exe # substitute the right number for PID
(with sudo if needed).
Notes:
- Some Unix(-like) systems do not provide
/proc, in Linux you probably have it. If not, maybe you can mount it on demand (well, in this case you should mount it before using pgrep or ps, because these tools may want to use /proc under the hood in the first place).
/proc may be mounted with hidepid, so maybe you need sudo pgrep …/sudo ps ….
- In general, if some wrapper or a script is involved then the name
ps would print as comm for the actual executable might be not as you expect, so filtering by the expected name may lead you to nowhere. Sometimes using command instead of comm can give you a better picture, but this also does not guarantee anything (because there are ways to alter the information: example A, example B). In some cases pstree with its options is useful to investigate further (not portable though).