You can not set the PID, but you can set the PGID: create or join a process group. Then you can send signals to this dedicated process group.
I had the impression that the new
systemd init system has some automation on this part, which is superior to having the process to write its PID to a PID file and then using it for controlling it.
systemd seems to switch to a "process group" (as I can understand this) before starting a controlled process, and then everything is in this group. So, you can control all the child processes by remembering the special "group".
If it functions like, this is superior to having the process to write out its PID, because you don't need to modify the program.
It might also be better then:
echo $! > /tmp/myprocess.pid
because this approach captures all the children of that process, too.
I don't have a detailed documentation at hand to support my words, but here is the general idea of what
systemd needs from cgroups,a nd this seems to match my impression:
Control Groups are two things: (A) a way to hierarchally group and
label processes, and (B) a way to then apply resource limits to these
groups. systemd only requires the former (A), and not the latter (B).
That means you can compile your kernel without any control group
resource controllers (B) and systemd will work perfectly on it.
However, if you in addition disable the grouping feature entirely (A)
then systemd will loudly complain at boot and proceed only reluctantly
with a big warning and in a limited functionality mode.