Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755904AbcJZATl (ORCPT ); Tue, 25 Oct 2016 20:19:41 -0400 Received: from sub5.mail.dreamhost.com ([208.113.200.129]:50395 "EHLO homiemail-a79.g.dreamhost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753185AbcJZATk (ORCPT ); Tue, 25 Oct 2016 20:19:40 -0400 Date: Tue, 25 Oct 2016 17:19:38 -0700 From: Krister Johansen To: Cao Shufeng Cc: linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, mashimiao.fnst@cn.fujitsu.com, ebiederm@xmission.com Subject: Re: [PATCH v4 3/3] Make core_pattern support namespace Message-ID: <20161026001938.GB2525@templeofstupid.com> References: <1477380536-3307-1-git-send-email-caosf.fnst@cn.fujitsu.com> <1477380536-3307-4-git-send-email-caosf.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1477380536-3307-4-git-send-email-caosf.fnst@cn.fujitsu.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1415 Lines: 28 On Tue, Oct 25, 2016 at 03:28:56PM +0800, Cao Shufeng wrote: > From: Zhao Lei > It will bring us following benefit: > 1: Each container can change their own coredump setting > based on operation on /proc/sys/kernel/core_pattern > 2: Coredump setting changed in host will not affect > running containers. > 3: Support both case of "putting coredump in guest" and > "putting curedump in host". Would you explain more about case #3 here? In particular, I'm curious what the impact is for systems that have already configured core_pattern with the understanding that the program might be invoked to handle either a host or a container core. In particular, is there any way to specify that the container handler fall back to the host handler? On the systems that I've configured, /proc/sys is mounted read-only in the container. The host has a special program run from core_pattern that determines which container generated the core. It then stores the cores in a directory that uniquely identifies the container. The cores are isolated on their own filesystem, and given a quota per-container. The eventual goal is to have a service evacuate the cores to an object store where we can make them available to the customer via a web service. Does your change still allow a global handler in the host to process cores from containers? Or is that behavior removed completely? -K