From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753415AbdBRPrM (ORCPT ); Sat, 18 Feb 2017 10:47:12 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:46088 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbdBRPrL (ORCPT ); Sat, 18 Feb 2017 10:47:11 -0500 X-ME-Sender: Message-Id: <1487432830.3981324.885228296.049484DB@webmail.messagingengine.com> From: Arun Raghavan To: Arun Raghavan , linux-kernel@vger.kernel.org Cc: Thomas Gleixner MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-715c2c0c In-Reply-To: <20170218083750.12305-1-arun@arunraghavan.net> References: <20170218083750.12305-1-arun@arunraghavan.net> Date: Sat, 18 Feb 2017 21:17:10 +0530 Subject: Re: [RESEND 2] [PATCH] rlimits: Print more information when limits are exceeded Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 18 Feb 2017, at 02:07 PM, Arun Raghavan wrote: > This dumps some information in logs when a process exceeds its CPU or RT > limits (soft and hard). Makes debugging easier when userspace triggers > these limits. > > Signed-off-by: Arun Raghavan > --- > kernel/time/posix-cpu-timers.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > Hello, > This has come up a couple of times in the past, but we haven't been able > to > resolve whatever issues were pointed out. > > In the mean time, we have frustrated users who don't know where they're > getting > a SIGKILL from, and I'd really like to have a way for people to not have > to go > through this. > > The issues that came up the last time were: > > 1. SIGXCPU messages shouldn't be needed since they can be caught: it's > still > useful to have the log because it isn't always possible to pin down > the > thread causing the problem in userspace. > > 2. SIGKILL logging should be centralised: there seem to be multiple > paths that > trigger a SIGKILL -- and it seemed a bit ugly to try to add a reason > parameter on all of them for the KILL case. Any other suggestions on > how to > deal with this? > > I'm happy to fix this up to actually make it this time, but if there > aren't > none, just pushing this out will make our lives a little less painful. That was meant to read -- "... if there aren't blocking objections to this, just pushing this out will make our lives a little less painful." -- Arun