[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
|
|
Subscribe / Log in / New account

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

Clearly we've been moving to a world where fds are the general way to refer to kernel objects, away from integer approach for PIDs.

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.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds