Rethinking race-free process signaling
Rethinking race-free process signaling
Posted Apr 5, 2019 14:58 UTC (Fri) by walters (subscriber, #7396)Parent article: Rethinking race-free process signaling
However there's an interesting thing here...you still really want a "human readable" and persistent identifier. With regular files, fds are obviously retrieved via...file names.
But this proposal is adding no such equivalent - /proc/<pid> doesn't solve the problem because it uses integers.
Now one of the core innovations of systemd was using cgroups as a way to just *group* processes. That model has further extended into modern container systems - e.g. in the model popularized by Docker, a "container" is a grouping of an image with cgroups, namespaces etc. Put another way...no one using e.g. Kubernetes really ends up thinking in terms of pids - you `kubectl delete pod/X`.
Back to cgroups...I think we can push admins and userspace more to thinking in terms of the cgroups. What if our identifiers for processes were more like (cgroup ID, u64)? And we had a system call that took that pair? It'd greatly ameliorate issues with pid reuse - at least you'd never end up killing a process in another cgroup.
We'd have /usr/bin/kill httpd.service/42 or so.