From owner-freebsd-arch@FreeBSD.ORG Wed Dec 3 11:57:06 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD40C17A; Wed, 3 Dec 2014 11:57:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F65BA91; Wed, 3 Dec 2014 11:57:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sB3BuuBG091206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 13:56:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sB3BuuBG091206 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sB3BuulB091205; Wed, 3 Dec 2014 13:56:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Dec 2014 13:56:56 +0200 From: Konstantin Belousov To: Julian Elischer Subject: Re: Process reapers Message-ID: <20141203115656.GR97072@kib.kiev.ua> References: <20141201185237.GC97072@kib.kiev.ua> <2BBA8329-C8F4-452D-B6C2-E129FCD6D666@me.com> <20141202093109.GG97072@kib.kiev.ua> <08032C01-B594-478D-927E-D7E52920ABEE@me.com> <20141203104616.GQ97072@kib.kiev.ua> <547EF4FA.60305@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547EF4FA.60305@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: arch@freebsd.org, Rui Paulo X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:57:07 -0000 On Wed, Dec 03, 2014 at 07:33:14PM +0800, Julian Elischer wrote: > On 12/3/14, 6:46 PM, Konstantin Belousov wrote: > > On Tue, Dec 02, 2014 at 11:46:27AM -0800, Rui Paulo wrote: > >> On Dec 2, 2014, at 01:31, Konstantin Belousov wrote: > >>> I could rename p1 to something else, but also short, since LIST_* > >>> constructs are long and clumsy. Might be, s/p1/rp/ ? > >> Yes, that works as well. > > Ok, I renamed p1 to reap. > > > > Does anybody have any non-formal comments about patch ? > > I would go as far as to say that the implementation details are > > really not that critical for the proposal. I am much more worried > > about the API design and its usefullness, > > A really easy way to tell you're rdealing with "init" from > debuggers/dtrace/etc > I have dtrace scripts that follow the parent process chain until they > get to pid 1. > in this case I'd probbaly want them to stop at the jail init (not 1).. How this note affects my patch ? I have no intent to patch somebody' else scripts. And, the question is, why do you need to trace the parent/child relationship till init ? > > Also, should a jail init have immunity from signals from within the > jail like init does? My opinion is that the ignoring of the default signal actions on the pid 1 is a safety measure to allow easier extension of the signal list. init(8) can achieve the same effect by catching the signals, but the code has to be updated when new signals are added. Issue there is not the signal handling, but a slopinnes in the kernel which cannot handle reaping of orphans. Since death of non-root reaper does not affects the system ability to reap orphans, there is no need to break signals interfaces. That said, the patch really has nothing to do with per-jail inits. The set of problems which should be solved by jailed init does not include the orphaned children reaping. It does not matter at all which process calls wait(2) for the orphan, be it in-jail or system-global init.