On 19.04.19 23:48, Christian Brauner wrote: > So is Android and we're not designing an interface for Android but for > all of userspace. > I hope this is clear. Service managers are quite important and systemd > is the largest one > and they can make good use of this feature. Maybe just talk about talking about service managers and not even mentioning systemd ;-) > That whole pargraph is about dismissing a range of valid use-cases based on > assumptions such as "way more common" and > even argues that service managers are special cases and therefore not > really worth considering. I would like to be more open to other use cases. ACK. Things like pidfd can make life for service managers a lot easier, and even allow whole new scenarios. For example, the monitoring part doesn't need to be the spawning process anymore. The spawner could send the pidfd to the monitor, eg. via unix socket. If we had plan9-like srv filesystem (something I've got on my todo list) we could even make the pidfd's available in the fs and so replace the old pidfiles (pidfile now would be really a process handle instead of just a scratchpad for writing down the pid). >> Joel indicated that he believes poll(2) >> shouldn't be supported on procfs pidfds. Is that your thinking as >> well? If that's the case, then we're in a state where non-parents > > Yes, it is. Why so ? IMHO, it would be much more useful, if another process can get the same process handle via procfs. This also would allow the scenario described above w/o srvfs: pidfiles could just be symlinks to the corresponding /proc files. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
