On Mon, May 10, 2021 at 09:39:02AM -0600, Jonathan Corbet wrote: > Christian Brauner <brauner@xxxxxxxxxx> writes: > > > Introduce the cgroup.kill file. It does what it says on the tin and > > allows a caller to kill a cgroup by writing "1" into cgroup.kill. > > The file is available in non-root cgroups. > > So I feel like I'm missing something fundamental here...perhaps somebody > can supply a suitable cluebat. It seems inevitable to me that, sooner > or later, somebody will surely wish that this mechanism could send a > signal other than SIGKILL, but this interface won't allow that. Even if > you won't want to implement an arbitrary signal now, it seems like > defining the interface to require writing "9" rather than "1" would > avoid closing that option off in the future. > > I assume there's some reason why you don't want to do that, but I'm to > slow to figure out what it is...? I think the consensus was that most signals are a process/thread-level thing and are rarely sent to more than one process, so sending them to all processes in a cgroup is never required. So far nobody came with any real-life use case behind SIGKILL. SIGSTOP/SIGCONT could be that case, but the cgroup v2 freezer is doing virtually the same and eliminates this need. Even SIGTERM which is often used before SIGKILL as a grateful termination attempt has to be sent to a proper process in the cgroup (e.g. container-level init or the main process in the workload). If a new case will arise, it will be possible to introduce a new interface file, but it looks very unlikely that there will be many such cases to justify a more generic interface. On the other side keeping it boolean makes it more consistent with the rest of the cgroup v2 api. Thanks!
