Date: Wed, 3 Dec 2014 13:56:56 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: arch@freebsd.org, Rui Paulo <rpaulo@me.com> Subject: Re: Process reapers Message-ID: <20141203115656.GR97072@kib.kiev.ua> In-Reply-To: <547EF4FA.60305@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kostikbel@gmail.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141203115656.GR97072>