From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 20:19:52 2013 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 04288D00; Wed, 7 Aug 2013 20:19:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDEA02696; Wed, 7 Aug 2013 20:19:51 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D65671203E0; Wed, 7 Aug 2013 22:19:34 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id BF79B28494; Wed, 7 Aug 2013 22:19:34 +0200 (CEST) Date: Wed, 7 Aug 2013 22:19:34 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> Subject: Re: Reliable process tracking Message-ID: <20130807201934.GA4918@stack.nl> References: <20130804134658.GC35080@stack.nl> <CDFF8851-0883-4D27-851A-36A9585499E6@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <CDFF8851-0883-4D27-851A-36A9585499E6@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch> List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 07 Aug 2013 20:19:52 -0000 On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Jilles Tjoelker <jilles@stack.nl> w dniu 4 sie 2013, o godz. 15:46: > > When shutting down a service or requesting status, rc.subr currently > > uses a combination of pidfiles and process names. This is fairly but not > > completely reliable once it is set up correctly (which can take a lot of > > work and possibly patching the daemon to use pidfile(3) from our > > libutil). It is also incapable of killing multiprocess daemons such as > > CGI web servers without cooperation of the daemon. > > I think what is needed here is a facility that marks a process and all > > of its descendants. Removing the mark should be a privileged or at least > > an unusual operation; no unprivileged function specified by POSIX such > > as setsid() should do this. > I've actually thought about that when I added setloginclass(2). It's > trivial to modify rc.subr to use su(8) to set login class for each > service. It should be trivial to modify pkill(1) and killall(1) to > add "-c" option to kill all processes in a given login class. There are some problems with su -c: * It refuses to set a login class name that is not in /etc/login.conf. Given that multiple instances of a service should each have their own kernel login class, it may make sense to allow specifying the login.conf entry separate from the kernel login class. * It always inserts an intermediate process to shut down the PAM session. This is not needed to start a simple daemon but not that harmful apart from performance. > Two caveats: > 1. Login classes, just like UIDs, are global, not per jail. This means when > you want to kill all processees in a login class, you should probably use > "-j" option to limit it to a given jail, e.g. jail 0. True. > 2. I'm not sure if pkill(1) has any special way of handling this, but there is > an obvious race condition between iterating over processes in userland > in pkill(1) and quickly forking processes to kill. Perhaps we should have > some kind of syscall to do it in a race-free way? Yes. -- Jilles Tjoelker