Re: [PATCH v3 1/5] cgroup: introduce cgroup.kill

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux