You know something is running. You do not know its number, and nearly everything you would like to ask about a process wants the number first.
macOS has no /proc. Everything below with a /proc path is Linux only, so it is the Pi, not this laptop. The Mac equivalents are at the bottom.
The one that matters for a daemon
AnswersIf it runs under systemd, the service manager already knows — that is one of the things running it under a service manager buys you.
systemctl status my-service # prints Main PID: 1234 (name)
systemctl show -p MainPID --value my-service # just the number
pid=$(systemctl show -p MainPID --value my-service)
cat /proc/$pid/io # bytes actually read and written
ls -l /proc/$pid/fd # what it has open right now
cat /proc/$pid/status # state, threads, memory
sudo strace -p $pid # every read and write as it happens
When it is not a service
pgrep myprog # by process name
pgrep -f 'python3 sensor.py' # by the whole command line
pgrep -a -f sensor # -a also prints the command
pidof myprog
Not thisps ax | grep foo finds the grep as well as the thing. pgrep does not, and that is the only reason to prefer it.
When you only know the port
AnswersOften the honest way in: you know something is listening and not what.
sudo ss -tlnp # every listener, with pid/name
sudo ss -tlnp 'sport = :1883' # just that port (mosquitto here)
sudo lsof -i :1883 # same question, older tool
The shell's own
echo $$ # this shell
echo $! # the last thing you backgrounded
On this Mac
pgrep -a -f something # works
lsof -p <pid> # what it has open — the /proc/fd job
lsof -i :1883 # by port
sudo fs_usage -p <pid> # the strace job, roughly
sudo dtruss -p <pid> # closer to strace, needs SIP off
Not thisThere is no /proc/<pid>/io here and no substitute for it. The byte counters are a Linux thing.